[Framework-Team] PLIP wishlists towards 3.0

[Alec Mitchell]

On Monday 13 March 2006 03:15, Martin Aspeli wrote:
> 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 3.0.
>
> There are a few UI PLIPs that limi has assigned:
>
>  #116 -- Large folder UI improvements: make large folders have a search
> interface, basically.

This should be easy to accomplish and is very sensible.

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

d'n'd reordering is likely to land in 2.5, sticky ordering is possible but 
unlikely.  Fortunately, it shouldn't be too difficult to implement either.

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

Everything could benefit from z3-ification IMO.  Though I've never used it 
myself, I've heard that the infrastructure provided by PlonePortlets should 
be usable with viewlet based portlets (which aren't available to us via Five 
yet at the moment).  This really needs input from people who have used it 
extensively and are familiar with the problem space it tries to address.

...

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

This has a lot of potential pitfalls.  We need to tread lightly here.

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

Honestly, while this stuff is sexy to show off I think it's somewhat useless 
in practice.  Modal interfaces make sense for most web applications 
especially where the dominant user task is not content creation or editing.  
There are a lot of details related to validation and reindexing that likely 
need sorting out for this to be remotely practical.  Additionally, as Rocky 
points out almost all content types use custom views which make no use of AT 
widgets, so this work would likely only benefit a few products, and none of 
the core types without extensive additional work to duplicate the default 
views using the AT widgets.  This project is likely to be time consuming and 
complex and the real-world payoff is, IMHO, really minimal (though it makes 
for sexy presentations).  I think labor would be better put into almost any 
other feature.

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

Using IE7 was a disaster last time it was attempted, it seems unlikely that 
it will be any different.  It's a worthwhile goal, not worth the expense.

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

This shouldn't be too hard, this seems like a good place to make use of an 
AJAX framework.  Before any work can start though this needs some clear 
specifications about how and where it would work.

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

Doesn't kupu offer some sort of reference creation as an option when linking 
in content with the ui?  It also seems that doing this would require 
tackling many of the same issues that wicked is trying to handle.  Might be 
nice to start with wicked, perhaps.

...

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

I don't think there's anything terribly wrong with the current situation, but 
there shouldn't be any real difficulty here once the magical DHTML schemata 
code is in place.  Getting the DHTML swiching to work properly is not 
necessarily an easy problem.  Because people often use multiple schemata to 
allow for fields whose state/vocabulary/visibility depends on values set in 
a prior schemata, making sure the appropriate data has been uploaded and 
validated before displaying another schemata is critical.

> 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

I know nothing about this stuff, and have never needed it.  Whit and geoffd 
have a good deal of knowledge in this space though.

> ** Versioning and staging **
>
> See: http://plone.org/products/plone/roadmap/8 and
> http://plone.org/products/plone/roadmap/131.
>
> 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.

The devs of CMFEditions (myself included) have not had any time lately to 
release a beta of any sort, but hopefully it will be ready to be recommended 
as an add-on product by the time of the release.  PLIP 131 seems very 
feasible, though I agree with Martin that it could use some rephrasing, 
hopefully we'll see some code for this soon.

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

I personally don't see this as a core feature, but that is up to limi.  
Perhaps Plone could provide the catalog indices and the catalog EIOW by 
default, and provide simple examples of the zcml needed to make a product 
ratable.  But, ratings seem to be something that are really only needed on a 
project by project basis.  I'm not sure what parts of ATRatings you think 
might be valuable here, but I'm of course open to anything that would 
improve the utility of this product.

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

This makes sense for certain usecases (tags on MP3s), but not all and I think 
it would be hard to come up with a ui that made sense across a broad range 
of usecases.  It's an interesting idea though, and it would be great to see 
some code.

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

Marshall is already a dependency as AT now includes it, though I think having 
an import story without an export story is a little problematic.  People may 
want to consider kickstarting ContentSetup development or looking into 
XMLForest, which seems promising.

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

Until we have a pure z3 product for providing this (which shouldn't be hard 
to make I think), it's not worth considering IMO.  fatsubscriptions may be a 
promising avenue for research.

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

The MailHost API is just mone method 'send()', this is true in zope 3 as 
well.  Our main problem at the moment is that SecureMailHost is a broken 
implementation of a MailHost, and makes the false claim that 'send()' is 
deprecated in favor of 'secureSend()', whose implementation is also 
extremely broken.  Zope 3 offers a very compelling mail story which includes 
both synchronous and queued mail transport (like MailDropHost except 
seemingly without the smart transaction handling) just by registering 
utilities.  We merely need to provide local utility based implementations of 
the z3 Mail mechanisms and perhaps make a stub 'MailHost' for backwards 
compatibility (and so that people can still drop in z2 mailers) which 
delegates to the utility.

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

It makes sense to integrate this if and only if there are parties willing to 
keep the tests up to date for every template/resource change.  We need to 
make sure that integrating another required testing methodology won't 
discourage developers from actually doing work.

> ** 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, please.

This is an absolute necessity, IMO.  If we don't move toward CMF 2.0 ASAP we 
will be stuck on our own little island, I think supporting 2.1 is probably a 
bit farfetched, but may become more feasible as things go forward.

This list as it stands is enormous, and it's important that the set of 
features can be completed in a 6 month timeframe, so let's not get too 
ambitious.  Of course only a small fraction of these are likely to have some 
reasonable implementation ready by the time you are ready to review these 
things.

Alec