[Framework-Team] Re: PLIP wishlists towards 3.0
rocky.burt at adaptivewave.com
Mon Mar 13 14:47:44 UTC 2006
I'll paste the comments I've added to the plips themselves. But I'd
like to first mention as a disclaimer that any new functionality being
built into Plone 3.0 that "does not" use Zope 3 style development
techniques (unless the feature isn't really code level or something
such) gets an automatic veto from me.
On Mon, 2006-13-03 at 11:15 +0000, Martin Aspeli wrote:
> #116 -- Large folder UI improvements: make large folders have a search
> interface, basically.
> #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.
> #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.
> #119 -- Contextual help: This is end-user, context sensitive help. I've got
> some code that does this, based on a custom catalog and AT content, that is
> fairly complete but needs some polishing. Again, a re-evaluation of this in
> terms of Z3 concepts would be welcome.
> #120 -- Tile links: This is related to making larger areas of the UI
-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.
> #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
> #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.
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.
> #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?
> #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.
Much too UI'ish for me to really comment on. I'll defer this to the UI
> #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.
> #126 -- Link type improvements: Tweaks to how we do direct-links, open-in-new-
> window and the assumption that links and favourites should be merged.
> #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.
> ** 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'm undecided about this simply because I haven't really had the need
for complicated categorization ability.
> ** 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 a
> thread about this on plone-dev.
I think proper versioning is vitally important to Plone. Staging and
working copies are good too.
> ** 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 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.
> ** 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.
> ** Bulk loading **
> See: http://plone.org/products/plone/roadmap/44
This seems a bit too much to bite off to me.
> ** 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
+1 on all of this. Specifically I've spent a bunch of time in
SecureMailHost and it *has* to at least be retired in favour of regular
MailHost. But moving to something z3 based would certainly be my
preference. 'course then we have to worry about exposing a z3 utility
as a tool (this is more general, do we expose all utils as tools?)
> ** 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.
> ** 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,
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.
AdaptiveWave - Content Management as a Service
Content Management Made Simple
More information about the Framework-Team