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
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
