[Framework-Team] Re: PLIP discussion summary

Benjamin Saller bcsaller at objectrealms.net
Fri Oct 28 21:09:36 UTC 2005


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.


>> 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.

>> 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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bcsaller.vcf
Type: text/x-vcard
Size: 261 bytes
Desc: not available
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20051028/a2a537ce/attachment.vcf>


More information about the Framework-Team mailing list