[Framework-Team] Re: PLIP wishlists towards 3.0

Martin Aspeli optilude at gmx.net
Mon Mar 13 18:13:57 UTC 2006


Rocky Burt <rocky.burt at ...> writes:

> >  #117 -- Folder contents improvements: sticky ordering, drag-and-drop 
> > ordering. See also: http://plone.org/products/plone/roadmap/101
> 
> Read this a couple of times and I'm still not "getting" the sticky talk.

I think it just means that you say "this folder is sorted by title" and it 
stays sorted by title. The tricky part is what you do when you sort by title 
and then want to sort manually again.

> >  #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
> 
> Zope 3 is heavily moving towards a viewlet architecture. I personally
> would rather see us move towards something based on viewlets. And if
> viewlets aren't ready for us, then we take the time to help make
> viewlets ready for us than using yet something else unique to plone.

Agree. That said, PlonePortlets are about more than that - they make portlets 
into proper content types that can be workflowed, and have permissions for 
things like who sees them in what contexts. I think some brainstorming with 
Geir and Helge would be good, but I agree that using Z3 views at the very 
least would be the way to go here.
 

> >  #120 -- Tile links: This is related to making larger areas of the UI 
> > clickable via some JavaScript magic.
> 
> -0 in its current state.  To be honest some of the new clickable area's
> bother me such as the headers for portlets (I accidentally clicked on
> this once -- and thought wha??)  Although I understand limi's latest
> comment that the plip is still in its infancy.

To be honest, I think that's just a UI/usability decision on what becomse 
clickable where.

> >  #121 -- Asynchronous loading of content views: AJAX to make the content 
tabs 
> > (view, edit, properties, sharing) load asynchronously
> 
> +1 on most of this.  But I have a comment: Why would this mean we'd have
> to give up bookmarkability?  I mean if we keep previous behaviour as
> well going directly to /edit or whatever would just make it do the right
> thing.  Personally I never bookmark content tabss but I do often give
> people I'm working with copied and pasted links to these things in a
> hurry.

Sorry, I don't quite understand what you mean. However, bookmarking the /edit 
is pointless. Bookmarking the actual object is vital, of course.

> >  #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.
> 
> +1
> This adds obvious immediate value to basic archetype content types (ie
> base plone ATContentType types).  But any serious applications I've
> worked with or built that are built on top of plone never use the
> standard views for custom content types and rarely use AT widgets on
> their custom views.  I guess these would remain unaffected by this plip.

I think it depends on how it's implemented - it could be made sufficiently 
easy to support this ("this div becomes this field when double-clicked") on 
custom views.

> >  #123 -- Alpha channel PNGs: Use the "IE7" to work around IE bugs so that 
we 
> > can use transparent PNGs for icons.
> 
> At one point I remember Limi toying with IE7 and saying it was far to
> slow to be useful to Plone.  Has something changed here?  Also, I seem
> to recall certain versions of Safari doing unacceptable things to PNG's
> when trying to auto-correct gamma sutff.  Isn't this still the case?

I think he mentions that on the PLIP, I'm unsure what the state of it is.
> >  #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. 
> 
> +1 on what this provides, but I think it needs more thought.  It seems
> to me that we could setup automatic subscribers for this sort of thing
> although I have to admit I've used z3 events sparingly at this point and
> don't know the extent of their effectiveness.  But what I would see is
> once a "link" is made, the two subscribe to delete/move events of each
> other and act accordingly.  But I'm really just brainstorming here.

Yeah, I'm also not quite sure how this would work in practice.

> > ** 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.
> 
> -1
> I personally don't see any really good reason to include this in core
> Plone.  I've never had a need to rate content nor have any of my
> customers/clients asked for it.  Having it available as a separate thing
> is good enough IMHO.

That's possibly true, however at the moment there isn't a good, generic way to 
plug something like this into the Plone UI. It'd likely be a separate python 
package whether we ship with it or not, but I think it's a use case that we'd 
do well to enable by UI mechanisms in Plone.

> > ** 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.
> 
> A resounding +1 on this one.  I really want plone to catch up to CMF or
> at least be as close as possible.  For the record, this should probably
> be changed to CMF 2.x as 2.1 will probably be out at that point which
> means if we want some things in CMF that directly benefit Plone, now
> would be the time to talk to the CMF people.

Agree. Want to work on it? ;-)

Martin




More information about the Framework-Team mailing list