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
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
