[Framework-Team] PLIP wishlists towards 3.0

[Raphael Ritz]

Martin Aspeli wrote:

>Hi guys,
>  
>
Hi Martin, hi fellow co-frameworkers,

>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.
>  
>
I thought that we are more on the reviewer's side but anyway
we should have an opinion.

>There are a few UI PLIPs that limi has assigned:
>  
>
quite a list; I'll comment inline as I see fit:

> [..]
>
> #121 -- Asynchronous loading of content views: AJAX to make the content tabs 
>(view, edit, properties, sharing) load asynchronously
>  
>
do we have an agreement by now on which libraries to build upon
(like rico/prototype or mochikit or on top of that azax, bling, or kukit 
...)?

> [..]
>** 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
>  
>
all I can say at the moment is that we do have some support in this
direction by now via our PloneOntology product. While it's not
addressing one of your prominent use cases  (aggregating content
in various ways) I'm sure it's something in the right direction.

>** 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.
>  
>
While I'm also opting for CMFEditions integration in the long run there
are some alternatives as of now:
1. It looks like we can have ZODB history support back if we want to.
2. Simple staging like "leave a copy published while working on a revision
and replace it only after approval of the revision" can be handled via 
workflow
quite naturally. I think there is even something like that published 
somewhere.
Shouldn't be hard to get that into Plone proper if we want to.

Taken together this would cover most peoples needs I think (biggest issue I
see is that you loose your history when packing the ZODB).

>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.
>  
>
Not having looked at Alec's "contentrating" yet I simply trust in it being
good and useful - because that's been the case for everthing I've seen
from Alec so far ;-)
Improving it with some of Geoff's good stuff sounds like the right 
approach to me.

>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.
>  
>
There is another twist to bulk editing as I see it:
Consider the case where you have a specialized folderish object where 
(some) children
are actually used to manage part of the content of the default view, 
i.e., looking at
the parent shows (some of) the children as well. Selecting 'edit' then, 
it would feel
natural to include the(se) children there as well.
If tried to illustrate this use case in my MySite tutorial where the 
custom Event
type is folderish to allow the addition of deadlines which are treated 
as individual
objects. IIRC AT has an ObjectManager-based storage to handle such cases but
as of now (I think) this doesn't support integrated editing.

It may be that the bluedynamics guys have implemented something like this
for the Zuccaro project. Does anyone know more here?

>** 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.
>  
>
Add bulk export here as well.

My number one use case for this is actually migration.
Imagine getting rid of in-place migrations by simply dumping your
content from the old site as some XML file and importing it into the
new one after configuring it to your needs, e.g. using a snapshot
created via GenericSetup.

There is actually some support for this in CMF by now (content setup
or similar)

>** 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 
>investigating.
>  
>
Just because I don't know: is Z3's mail handling asynchronous as with
the MaildropHost from Jens?

>
>** 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 was only recently that I wrote my first (Plone)Selenium-based tests 
for a
product of mine. I was pleased to see how easy and effective this can be.
I think this isn't much of a development issue but rather of educating
people by advertising best practices (and insisting on them for core 
contributions).

>** 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.
>  
>
I think it would be a shame if Plone 3.0 would not ship with CMF 2.0 (or 
2.1 by
that time)

http://www.zope.org/Products/CMF/docs/roadmap

Now one thing appeared to me that I find strange:
I thought that Plone 2.5 is focussing on UI  yet you mention quite
a number of UI issues in the beginning.
On the other hand I thought Plone 3.0 should focus on pushing the
underlying framework forward yet I see no (explicit) mention of
further adopting Zope 3 style approaches.
You even seem to imply that it might be too early to adopt CMF-2.0
which I would say we should at the very least aim for.

Other than that: How about Zope 3 schema base content types?
We do have 'plone_schemas' from Alec since a while now and
even though this might be considered something to be introduced
at the CMF layer rather than Plone proper we might consider contributing
there as well. Same for switching to an event-based system, btw.

>
>...
>
>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! :)
>  
>
Raphael (still hoping I can make it for that sprint but it's tight )

>Cheers,
>Martin
>
>
>_______________________________________________
>Framework-Team mailing list
>Framework-Team at lists.plone.org
>http://lists.plone.org/mailman/listinfo/framework-team
>  
>