[Framework-Team] PLIPs for 3.1

[Tom Lazar]

hi everybody,

here's my feedback on the plips submitted by martin.

On Dec 2, 2007, at 6:19 PM, Martin Aspeli wrote:

> 1. http://plone.org/products/plone/roadmap/184 - Ship additional  
> portlets
>
> This is actually raised by Jon Stahl, but I've been involved in the  
> implementation of the portlets he's talking about (collection,  
> static text, document rendering). I'd like to tidy up the portlets a  
> bit (especially if the formlib PLIPs below are accepted and  
> implemented). After that, this should be as simple as deciding to  
> ship with a few extra eggs.

definitly +1 on the static content portlet with richtext editing. dito  
for the collection portlet. not sure whether it makes sense to ship an  
rss portlet, though. pulling in external content is a nice idea but  
including it in the default setup somehow doesn't feel right. few  
people will use it, i assume, and we shouldn't slip into feature  
bloat, just 'because we can'.

i'm also not sure how to treat static portlets conceptually. i.e. as  
pages (that just 'happen to be displayed in a column') or as non- 
content. this raises further questions, i.e. how to treat their  
content when searching a site? their content should definitly be  
included in searches IMHO, but how treat them in result listings?  
since they might be conext sensitive they really don't have an  
absolute_url. OTOH using a central place to instantiate the static  
portlets which are then just referenced in the assignment instances  
(as suggested by jon in the plip) doesn't seem quite right, either  
(although it does solve the search and absolute link problem nicely).

any suggestions here from my fellow board members?


the following three plips (200, 201 and 202) are based on the fschulze- 
optilude-usw branch of plone.app.form, which i've tried to check out  
using a current version of ZopeSkel (1.3) and plone.recipe (3.0.4) but  
failed with a version conflict, since the recipe already includes  
plone.app.form. i tried various buildout.cfg changes without success  
and then briefly considered but ultimately refrained from using  
ploneout, since that (presumably) is based on plone trunk a.k.a. plone  
4.0, so the following comments are based on reading the plips and  
looking at the abovementioned branch's code, only.

(perhaps somebody can offer a quick way of getting ones hands on an  
instance of the branch or i'll just wait for the review bundle.)

> 2. http://plone.org/products/plone/roadmap/200 - Kupu formlib widget
>
> We need a Kupu/WYSIWYG widget for formlib-base forms. I'd like to  
> thise this in portlets as well as formlib-based content types. The  
> implementation here is largely complete.

+1 on the idea, especially including portlets. it would be nice to be  
able to configure what features/buttons are included when rendering  
kupu as often it's really overkill and increases pageweight.
>
>
> http://plone.org/products/plone/roadmap/201 - Improved  
> UberSelectionWidget
>
> This is about AJAX-enabling the UberSelectionWidget. Andreas and  
> Florian and I have started this work already - it just needs a bit  
> more JavaScript love. Again, I'd like to use this widget in a few  
> more portlets, content rules and formlib-based types.

+1 this, too, sounds very cool and desirable. i'm especially keen on  
the 'quicksilver like' functionality. i'm probably hoping for too  
much, though, when imagining myself typing 'fbr' to match 'foobar',  
since i assume that would require a completely new kind of index, no?


> 3. http://plone.org/products/plone/roadmap/202 - KSS inline editing  
> and validation for formlib forms

+1 on the design goal. i really missed this feature on a recent  
project ;)

in the demo template, where is the kssattr namespace defined, which is  
used in i.e. kssattr:fieldname="title". is that something new from  
this plip or a general convention? it seems a bit redundant, since we  
also have tal:content="context/Title". then again, it is of course,  
nice to be able to 're-wire' fields straight in a template. but  
perhaps, in a grok/RoR spirit we could come up with some kind of  
default mechanism that maps the kss fieldname with the context.

the rather clumsy class attribute is generated at runtime via KSS, i  
assume, so there's probably no need to make that a bit more 'human  
friendly'.

> 4. http://plone.org/products/plone/roadmap/203 - Manage portlet  
> assignments with GenericSetup
>
> This is about making it easier to set up portlet assignments in GS  
> profiles. I have a design for this, but no code yet - I plan to work  
> on it over Christmas.

+1 on the design. this is pretty much exactly what i would like to be  
able to do ;-)

> 5. http://plone.org/products/plone/roadmap/204 - Manage content  
> rules using GenericSetup
>
> This is quite similar to 203. Again, no code, but I know how to do  
> it and hope to get it done for January.

can't really comment on whether the suggested syntax is entirely  
logical and complete as i'm not familiar with content rules but i must  
say that it looks very clean and straightforward. so +1, too.

i'm really looking forward to being able to take these for a spin,

cheers,

tom