[Framework-Team] Re: PLIP wishlists towards 3.0

Martin Aspeli optilude at gmx.net
Tue Mar 14 13:12:09 UTC 2006

Alec Mitchell <apm13 at ...> writes:

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

Absolutely... I know PSOL use PlonePortlets in pretty much all their
deployments. I'd really like some more info on how viewlets work, though.

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

Such as?

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

I used to be of this opinion, but then I wrote Poi :-)

For some use cases, transactional editing is more sensible. In cases where you
have a lot fields (e.g. on the Poi issue type), not having to switch context to
the edit tab to correct a mistake is really nice. Even for changing the title or
description of a document, I think this makes sense.

I also think it's something you should be able to turn on or off site-wide. 

But we can make it reasonably easy to use. I belive Bing makes it possible at
least, to mark a given <div> or similar in the view as being mapped to a given
field. That way, it can register the necessary JavaScript so that when you
double click inside that <div> it finds the field and renders it in-place. That
doesn't mean you have to use the view widget in its entirety, although the
default view widgets would probably do this as well.

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

It does - UID-based links, which are rendered to proper links when the document
is viewed. I thin it covers most of the problems, although limi is scared of
anything that may give us illegible URLs :-)

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

Right - I think we need to work out what use cases would and wouldn't work here.
Schematas need to be fixed though, the current UI is so bad no-one uses them
unless they're really forced to. :)

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

I think it's one of Plone's biggest missing pieces at the moment. Like a
colleague of mine said, "the definition of a CMS is that it lets you view
content in different ways without having to make copies of that content".
Currently, we only have smart folders to do that, which are useful, but
imprecise as categorisation tools. It's a tricky problem domain though, and we'd
need to get it right. I'm hoping to devote time to this during the Archipelago
sprint, if I can solicit some help.

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

That's the direction I'm leaning in too - see plone-dev as well.

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

My main gripe is that it's hard to make a proper UI for this at the moment
without patching main_template or similar evils. I'd like Plone to have a
generic UI mechanism to handle this kind of use case. Whether we ship with
rating or not would then just be a release manager choice.

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

Mostly Geoff's crazy formulae. I'd like to talk to him about it at least.

> > ** Bulk editing **

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

I've just found myself wanting this several times. It may become a pet project.
It doesn't necessarily need to be part of core Plone, though, it could be an
add-on module that provides some specific view logic, for example.
> 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.

Cool. I'm hoping someone will champion this - it's important to claim you can
get stuff into and out of Plone easily.
> > ** 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.

Cool. I think this would be nice - mail support is always hard.

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

Absolutely agree. I'm kind of hoping we'll get an army of Selenium testing
volunteers, but that may not happen ;-)

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

Cool. :)

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

Hey, so was the list in Amsterdam. :) (of course 2.1 slipped...) I completely
agree with both you an Hanno - we need to stop being over-ambitious and pushing
too much. I'm mostly trying to air this now so that we can ramp up some
enhusiasm for the Archipelagio sprint and get going there quickly.


More information about the Framework-Team mailing list