[Zope3-dev] DISCUSS: getting rid of the obscure "Title" convention

[Paul Everitt]

Wolfram Kerber wrote:

> Tres Seaver wrote:
> 
> 
> 
>>Martijn Faassen wrote:
>>
>>
>>>Lalo Martins wrote:
>>>
>>>
>>>>at:
>>>>
> http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SecurityFra
> mework
> 
>>>>
>>>>>Interface IPrincipal
>>>>>getTitle()
>>>>>  Return a label for the principal
>>>>>
>>>>>
>>>>So, why is it getTitle() and not getLabel()?
>>>>
>>>>The use of the Title property/method is an obscure convention in Zope2
>>>>and, in most places, a misnomer.
>>>>
>>>>
>>>I agree getLabel() would be a better name for this method. While titles
>>>are frequently indeed used to fill <title> </title> in HTML pages,
>>>they're also frequently used for other purposes, such as in
>>>tables of contents of objects, or indeed as a label in Formulator fields
>>>(though I'm to 'blame' for the latter :).
>>>
>>>So calling them labels sounds like a good idea.
>>>
>>'Title' and 'Description' are standard (DublinCore) field names
>>for the metadata these fields represent.
>>
> 
> I was thinking that the ComponentArchitecture would make such considerations
> obsolete, there would just be a DublinCore presentation/view !?


Sure, it _might_ work out that way.  However, there will be a core set 
of metadata required by every component, and perhaps a higher level of 
metadata supported by every web-managed component.  It is important to 
choose a good metadata scheme that balances rich vs. light.

Hmm, this brings up an interesting question regarding a question.  Can 
the component architecture provide a formal, measurable answer to the 
question: "What is content?"?  Even better question: Should Zope3 have 
any concept of "content"?

As some know, I've had a broad, ambitious idea for expanding the meaning 
of content.  Others have pointed out that making it too broad renders 
the definition ineffective.

Every instance doesn't need to be a piece of content.  Every persistent 
instance (zodb) doesn't need to be a piece of content.  Beyond that, 
it's pretty much fair game.

To me, content is business information to which you apply a suite of 
services, such as workflow, versioning, cataloging, etc.

In this scenario, "Document" is a pretty obvious winner as content.  But 
does this mean instances of a lower-level, non-Zope-specific document 
component, or a higher-level, Zope-managed component?

Here's a more controversial example.  Is a "View" (or presentation 
component) a piece of content?  Doesn't feel like it, as it doesn't feel 
like information that site visitors come to read and search for.

But then again, don't you want to apply a suite of standard services to 
"View"?  Don't you want to establish relationships between revisions of 
views and the content being presented on a certain day?

Of course, if "content" expands to this point, it's just another word 
for "component".  I think the component architecture has done a good 
enough job of formalizing the "applying services to business resources" 
concept that we can get back to a more restricted question.

Is "content" something with a specific interface (or set of interfaces), 
or meets some other criteria?

--Paul