On 18 mei 2008, at 18:37, Martin Aspeli wrote:

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

Yes, it was a bad choice to tie the description to the content back in the days. The problem started with placing the description widget at the top of the edit form while it should be at the bottom. After all, it is just before you save, you have to think of one or two sentences to describe WHAT the object is about for when people search for that item and see it in the listing. By placing it at the top, people always assume it is a lead in. Bad choice. Especially when people use it as a lead-in. Lead-ins are usually bad for search overviews. It hardly ever describes what the item is about.

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.

If people want a teaser or a lead-in, then the best way would be to add such a field. Then it's part of the content, can be placed on top of the edit form, just before the body (it's a lead-in after all). But I agree that the impact is maybe a bit too large.

Danny Bloemendaal

Framework-Team mailing list

Reply via email to