[Framework-Team] Re: PLIP wishlists towards 3.0
optilude at gmx.net
Mon Mar 13 17:41:21 UTC 2006
Raphael Ritz <r.ritz at ...> writes:
> I thought that we are more on the reviewer's side but anyway
> we should have an opinion.
I don't think that means we can't discuss what we'd like to see in the big
picture, though. :)
Perhaps this is more appropriate on plone-dev - if you think so, I'll repost
> 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
No, and I think this is an important thing. I proposed we ask for some designs
from proponents of various frameworks earlier. Perhaps now is a good time to
put out such a request?
> 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.
Right ... I took a look at it, and it confused me a bit. Perhaps you could
weigh in on the original thread about how PloneOntology meets the use case?
> >** 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
> >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
> quite naturally. I think there is even something like that published
> 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).
Can you detail exactly how the UI of such a workflow would work?
I quite like the principle of PLIP 131, though as you'll see on plone-dev, I
think Maik's thinking about it backwards - he wants to implement it using
LinguaPlone, as opposed to design it on its own and make LinguaPlone support
Maik's idea is essentiall workflow-based, but relies on a second "staging"
workflow in the workflow chain that applise to staged versions (i.e. it's
either current, working-copy or obsolete). With this type of staging, history
diffs could use a combination of in-ZODB revisions and diffs across different
stages (I think HistoryAware.py could be easily patched to support this).
Diffs across stages are of course more reliable, since old staging versions
would have to be manually cleaned up and not be subject to packing.
> 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.
Me too! :)
> 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.
Yeah, I get it. The obvious way of approaching this would be to use adapters
to abstract this away so that objects that have such particular needs could
provide them via an appropriate adapter. I think this is an edge case still.
> 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)
Yes. I'm hoping Rob Miller will champion this, since he seems to be leading
the effort around GenericSetup and was talking about the benefits of it for
migrations. Marshall, xmlio, GenericSetup, ArcheCSV ... there needs to be some
clarity about what works and what's possible.
> Just because I don't know: is Z3's mail handling asynchronous as with
> the MaildropHost from Jens?
I think so, but I'm not 100% sure.
> 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
We have process PLIPs you know :)
> I think it would be a shame if Plone 3.0 would not ship with CMF 2.0 (or
> 2.1 by
> that time)
I agree. It's a risk assessment matter, though.
> 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.
No, no, no - you got it backwards. 2.5 is the framework release, 3.0 is the
UI/functionality release. Which is why CMF 2.0 may be more appropriate for
3.5, but then that may just be waiting too long to get those benefits.
> 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.
I think that will still be a natural consequence - new things should certainly
use Zope 3 approaches wherever possible.
> 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.
Agree. Although I think this may take some time - the CMF guys aren't really
sure how plain Zope 3 types would interact with their types systems and menus.
The support needs to happen there first, really.
> Raphael (still hoping I can make it for that sprint but it's tight )
You really should! :)
More information about the Framework-Team