[Framework-Team] Re: PLIP discussion summary

Michel Pelletier 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

+1

>
>_______________________________________________
>Framework-Team mailing list
>Framework-Team at lists.plone.org
>http://lists.plone.org/mailman/listinfo/framework-team
>  
>




More information about the Framework-Team mailing list