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,



Framework-Team mailing list

Reply via email to