[Framework-Team] PLIP wishlists towards 3.0

Martin Aspeli optilude at gmx.net
Mon Mar 13 11:15:50 UTC 2006

Hi guys,

I guess this is why we exist, so... I think we should discuss a bit what kind 
of things we'd *like* to see PLIPed, discussed and possibly included in Plone 

There are a few UI PLIPs that limi has assigned:

 #116 -- Large folder UI improvements: make large folders have a search 
interface, basically.

 #117 -- Folder contents improvements: sticky ordering, drag-and-drop 
ordering. See also: http://plone.org/products/plone/roadmap/101

 #118 -- Ship PlonePortets: PlonePortlets is in use in production and quite 
solid. One thing we may want to investigate is whether it could benefit from 
some Z3-ification after Plone 2.5

 #119 -- Contextual help: This is end-user, context sensitive help. I've got 
some code that does this, based on a custom catalog and AT content, that is 
fairly complete but needs some polishing. Again, a re-evaluation of this in 
terms of Z3 concepts would be welcome.

 #120 -- Tile links: This is related to making larger areas of the UI 
clickable via some JavaScript magic.

 #121 -- Asynchronous loading of content views: AJAX to make the content tabs 
(view, edit, properties, sharing) load asynchronously

 #122 -- QuickEdit mode: This is in-place editing of AT fields (double click a 
field in the view, and get an in-pace editing widget). I believe Ben Saller's 
Bling work makes this quite easy.

 #123 -- Alpha channel PNGs: Use the "IE7" to work around IE bugs so that we 
can use transparent PNGs for icons.

 #124 -- UberSelectionWidget: limi's grand plan for a generalised LiveSearch 
like widget that can search any large vocabulary, for use both in AT schemata 
and more generally in Plone.

 #125 -- Link integrity (no more 404s): Involves keeping track of e.g. when an 
image is referenced by a document. The idea is that an on-save handler would 
go look for objects referenced by the current object and mark them as 
referenced-by that object. I'm unsure how to generalise that properly, though. 

 #126 -- Link type improvements: Tweaks to how we do direct-links, open-in-new-
window and the assumption that links and favourites should be merged.

 #127 -- Move the 'properties' tab to the 'edit' tab as a fieldset: This 
depends on merging the DHTML fieldset switching code so that AT schematas do 
not suck.

Then there are some other PLIPs and noises in the community I think we shoud 
consider more carefully. Other suggestions are also welcome of course.

** Categorisation/taxonomies **

This is my biggest pet peeve at the moment. It really sucks that Smart Folders 
are the best way we have to categorise the same content in a single location.

I started a thread about this on plone-dev a while ago, and I've been trying 
to learn about RDF and Topic Maps. I feel I need the help of someone with a 
bit more experience, though - topic maps are powerful but complicated. 

See also: http://plone.org/products/plone/roadmap/103

** Versioning and staging **

See: http://plone.org/products/plone/roadmap/8 and 

It seems to me that the full-on versioning use cases are handled best by 
CMFEditions, whereas PLIP 131 is about staging and working copies. There's a 
thread about this on plone-dev.

I would really, really like to see at least the catalog-based staging (or 
something similar and simple) happen in 3.0. CMFEditions may be integrated 
more closely or at least be called "highly recommended" in the same way as 
LinguaPlone is now, if it's proven in a couple of real world implementations. 
The staging use case is really seconary to CMFEditions and can be handled by a 
more lightweight process such as the one proposed in PLIP 131.

This PLIP looks fairly good to me, though there are some unresolved issues 
around UI and workflow.

** Content rating **

We should have a generic way of making content ratable. alecm's new 
contentrating product is simple and Z3-ish. Some of the wisdoms from Geoff's 
ATRatings products should probably be rolled into it. ATRatings is a really 
nice piece of code, but it's never seen enough maintenance to make it to a 
proper release. It also suffers from lack of a good generic UI since Plone 
doesn't have any provisions for it (a portlet is about the best you can do). 
Hence, I think this deserves a PLIP for 3.0.

ATRatings also does external databases and hit counting, neither of which I 
think should be in scope for such a PLIP.

** Bulk editing **

A generic way of selecting an arbitary number of content items (e.g. from 
folder_contents) and editing them in bulk on a grid or by simultaneously 
editing the same field of multiple objects. This would most likely have to 
happen at the AT field level behind some abstraction so that we could make it 
work for Z3 content types as well. The hard part is deciding how we select 
which fields are editable. 

One solution would be to select multiple items, click "bulk edit" and then see 
a page where you could pick the fields to edit. The list of editable fields 
would be the intersection of all fields available on the content types 
selected. These would then be turned into a grid of editable fields with a 
single save command, possibly with some UI to select all fields in a given 
column and edit them simultaneously to change that field for all objects in 
one operation.

** Bulk loading **

See: http://plone.org/products/plone/roadmap/44

It should be easier to bulk-load a lot of content into Plone, and also to bulk 
export to CSV and XML. Marshall, ArcheCVS and some similar product from Enfold 
are promising here. I'm not sure whether this needs to be a Plone PLIP, but I 
think it's an important use case that would build our interoperability story, 
and deserves further discussion.

** Subscriptions and mail notifications **

Having notifications when content is edited, commented-on etc. is a fairly 
common requirement. This is difficult for two reasons: Firstly, each 
implementation needs to re-invent the mechanism of subscription, which can get 
complex when you want people to be able to opt in or opt out. If Plone could 
provide some generic way of handling subscriptions, a pattern for making mail-
out templates and a simple way of sending such email, that would be very 
useful. In process, we should enable this for standard comments (toggable via 
a site setting).

Secondly, the MailHost API, and especially SecureMailHost, sucks. I think that 
the Zope 3 mail handler would be usable via Five, and this is worth 

** Selenium and functional testing **

See: http://plone.org/products/plone/roadmap/100

With new UI features, it becomes especially important to test things properly. 
Selenium/PloneSelenium/Zelenium seem to be the most common way of doing TTW 
integration testing. I think we should investigate how hard it would be to 
integate such tools into our deveopment cycle properly.

** CMF 2.0 **

Rob mentioned he was interested in seeing CMF 2.0 in Plone 3.0. I'm unsure how 
radical a change this would be, both for us and for third party developers, 
and how mature CMF 2.0 would be in a few months' time. Opinions on a postcard, 


Those are the things that come to my mind. I would really like to kick off a 
discussion about what is and what isn't desired, feasible or sensible. We 
really need to have the major PLIPs solicited before the sprint in Norway at 
the end of April! :)


More information about the Framework-Team mailing list