[Framework-Team] Re: PLIP discussion summary
michel at cignex.com
Mon Oct 31 19:04:43 UTC 2005
Benjamin Saller wrote:
Ok sorry to piggyback on ben's responses here but I'm rushing to catch
up and Ben has set a precedent:
> whit wrote:
>> thank you for such a nice concise summary of your views. i'm
>> forwarding this back out to the rest of the list.
> Nice enough that I will piggyback
>>> Here is a summary of the discussion from my point of view:
>>> 100 (Selenium): -1 No urgent need for integration into plone core.
>>> The 3rd party framework works and and will continue to do so.
>>> People can write selenium tests for plone and their own products
>>> easily without selenium being directly integrated into plone.
> -1 also , there hasn't been an outpouring of tests using this
> framework, with a real cultural commitment its simpler to let this be
> an external product maintained by people who care. In its current form
> and usage those tests will suffer bitrot.
Well I'm +0, I like it a lot and I think it might even be suffering from
some bitrot now, so that inclusion in Plone will force us to keep it up
to date, but that's a drag and some recent disadvantages that Jim
pointed out at the conference in Selenium have made me luke warm. But
that doesn't mean we don't need *something* like it.
>>> 102 (PlonePAS): +1 This is very much needed as GRUF is inflexible
>>> and unmaintained. However, we need to ensure that migration from
>>> existing GRUF (and pre-GRUF) instances is well supported.
> +1 to getting off GRUF.
+1, CIGNEX has an interest in getting this to happen but I can't commit
on any kind of resources at this point. Would a follow-up sprint to the
first SJ sprint be in order? Does anyone know the issues we left on the
table last year?
>>> 105 (Views in Plone): +1 To the concept. Though this PLIP is not
>>> something that will result in specific code which needs to be
>>> reviewed and approved (except perhaps the global_defines stuff), it
>>> does outline one of the major goals of the 2.2 release. Without
>>> this 2.2 is a bit meaningless.
> I'd argue that things like Five events are much more important that
> this viewification but this can also prove an important step moving
> forward. While there is little gain in its present form (and even so
> associated cost/loss) I am still +1, its a logical step forward.
>>> 106 (Views for Nav elements): +1 this could potentially result in
>>> some speedup, and allows for reimplementation of some of the
>>> cruftier code in plone. We need to flesh out what the new
>>> view-ified portlet architecture will look like, because we are going
>>> to be stuck with it, the PlonePortlets folks should certainly be
>>> included, as I'm sure they have opinions on this.
> While +1 on the concept I think we are going about this slightly wrong
> right now. Currently these bind to 'for="*"' which is not what I think
> we want, we do have ideas about contentish-interfaces and we should
> use those. Things like request.get("xxx", computeX()) where computeX
> is always called are not ideas we want to push into replication. I
> gripe about impl details because these examples will be copied by most
> people trying to use this technology.
I'm +1 too; and I feel it that for="*" is a problem and that we need to
formalize our ideas into concrete interfaces. Perhaps this needs to be
addressed in a follow up PLIP.
>>> 107 (Five based navtree): +1 The current usage of an AT schema
>>> element to determine navigation visibility is hacky and is a really
>>> bad example of mixing content with presentation (both Tiran and I
>>> argued against this originally, but the UI folks won out). I am not
>>> at all familiar with MenuGenerator, and what it provides, or how
>>> exactly we will make this dependency soft. A cursory look makes me
>>> think that it is a complex (though nice) bit of code to be bringing
>>> in just to make one tree display.
> I think we'd want to tell a caching story here rather than leaving it
> as an exercise to the reader, once we have events the menu object can
> subscribe to the changes that would update it and we have a very fast
> core for doing this type of namespace manipulation and display.
> +1 provided we can get people interested in sustaining it.
>>> 108 (zope3 i18n): +1 Hannosch has done great work here, and there
>>> are many compelling reasons to go in this direction, and the
>>> downsides are minimal.
> +1 we need this and its in good shape
>Framework-Team mailing list
>Framework-Team at lists.plone.org
More information about the Framework-Team