[Framework-Team] Re: [Plone-developers] moving description to a viewlet
optilude at gmx.net
Sun May 18 16:37:13 UTC 2008
Wichert Akkerman wrote:
> Previously Martin Aspeli wrote:
>> This is a fairly substantial (if subtle) change. As soon as you do this,
>> everyone who's got a custom view template that follows the conventions
>> (i.e. tons of third party products and custom content types) will start
>> to see the description twice. That's unacceptable and will require
>> everyone to rewrite.
> Fair enough.
>> Turning a viewlet off for one type only is also a bit awkward. You end
>> up having to customise for the given context type with a viewlet that
>> renders nothing.
> Hmm hmm. Perhaps there is an abstraction or hook missing here. It's a
> shame the viewlet mechanism does not have an available flag like
> portlets do. Still, you could add that to the __call__ method.
Limi has some UI ideas that would see portlets and viewlets unify
somewhat. I think it'd be possible to have such a flag (and the ability
to more easily move viewlets around different viewlet managers than it
>> I'd rather just advise people to hide the documentDescription div with
>> CSS if they want it gone site-wide, and to customise if they want it on
>> a per-template basis. It's way easier to customise a template and remove
>> or move a div than it is to find out where the damned viewlet came from. :)
> You'ld have to customize every view template for every content type in
> your site. That can be quite painful.
For a site-wide switch, definitely - unless you hide with CSS, which may
not be so bad, it's metadata after all and may make sense in search
results or for blind users.
> For a site I'm working on now that
> would easily be over 20 separate templates. Creating/overriding a single
> viewlet is much simpler and much more maintainable.
But makes it much harder if you want to make it a per-type decision.
>> To make this argument a bit more general - viewlet managers are
>> primarily slots in which generic UI can be plugged in. For example, if
>> you have a tagging solution and want to show a tag cloud for all
>> supported types, you could insert that as a viewlet without having to
>> customise every template. Ditto with the way Iterate displays messages
>> depending on whether the IWorkingCopy marker is set.
> I want something just as general. I want that bit of metadata (which the
> description really is, and if Plone didn't show it in so many places I
> would move it to a different fieldset as well) to go away from my
> content views everywhere.
I think that point of view makes sense if we really do designate DC
Description as a metadata field that isn't primarily used in content
display. Right now, that's not our policy (as you point out, the
policy's somewhat muddled on this point), and so this type of generality
isn't warranted, IMHO.
>> An object's description is intimately tied to its schema. A "description
>> renderer" probably isn't a useful concept on its own. The decision on
>> whether and how to render the description is part of the view logic of
>> the object in question and should thus, IMHO, remain closely linked into
>> the view template, not indirected away to a place where it's harder to
> I just feel that the description is not part of the content. It is
> metadata: it describes what the object is about. As such it does not
> have business appearing in view templates, especially not in the way
> it does now. That is a mistake Plone made long ago, and something we
> should fix at some point.
I think with a bit more discussion and input, we could arrive at this
conclusion and consider a policy switch, but I think for 3.x the ship's
sailed. For a lot of people, the way that Description is being used in
views makes it a de-facto part of the "content" schema (rather than the
"metadata" schema) and so something that users very much think of as a
"lead-in" just as much as an abstract "description for independent
listings". We can't ignore that sunk assumption either.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
More information about the Framework-Team