[EMAIL PROTECTED] wrote:
On 2/7/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
Andreas Hartmann wrote:
[EMAIL PROTECTED] wrote:
A Document is XML. An Asset is not XML.
IMO we should use the term Asset for all content items, whether XML
or not. I don't see the need for differentiating between XML and non-XML
assets.
All content-related issues would be the responsibility of the AssetType
(formerly known as ResourceType / DocumentType).
For instance:
[Many examples of using Assets that are XML-based.]
I have a couple of thoughts/suggestions/objections.
First, we need a superclass for objects placed in Content. This
superclass contains identifiers, security information, and
Translations (Nodes for different languages). Each Translation
contains Revisions (Nodes for historical versions of each
Translation).
For the name of the superclass, we were discussing "ContentItem" or
"Resource".
Yes, and neither of them seems to win.
Now you suggest "Asset" right after a discussion that
wanted to define Assets as parts of a Document.
Yes.
Lenya 1.2 defines an
Asset as an uploaded file. Why would we create a new definition of
"Asset"? Are we trying to confuse everybody?
I don't mind re-defining the meaning of the term Asset.
Second, we need to separate XML and non-XML. Storage could use
<resource type="XML"> and <resource type="non-XML">, but programming
requires different class names for each.
Does it? I'm not quite convinced of that ... The class could just provide
input and output streams to store arbitrary content. Which content
can be stored would be determinded by the (asset/resource/...) type.
XML data can be aggregated, transformed, and serialized. "Document"
is well-defined in XML and Lenya 1.2 as an XML Document. Why would we
change that?
We wouldn't. We just don't need a Document class.
Documents then have Types based on the DTD, (and
possibly a PI or other XML.) In Lenya 1.2, the doctype parameter
decided the Type. In 1.4, every Document should know its Type, but
can be overridden (ignored) by Modules. XML data can be edited using
the CMS GUI.
For Non-XML data (Assets), there will be different functions. Non-XML
data needs to be downloadable (serialized as binary?). It cannot be
transformed. It might be converted to Base64 for use as XML, but
would use the BinaryToBase64 Module, which is not part of core.
Assets can be uploaded; they cannot be edited using the CMS GUI.
Why? You could use a text editor, or an HTML (non-XHTML) editor.
Or even an editor to manipulate images.
Third, there are several options for the datastore:
1. Content/Resource[Type="XML|Not XML"]
My experience suggests using Elements will prove much easier (less
code) than using an Attribute for something so basic. It is the
difference between:
<xsl:apply-templates select="resource[type='xml']"/>
and
<xsl:apply-templates select="document">
It is one extra test (repeated extremely often) that can be avoided by
better design.
The XML representation is not directly related to the fact if there
are subclasses for XML-based and non-XML-based assets/resources/...
2. Content/Document and Content/Asset
It should be easy to get all the Nodes of one Type.
I don't consider "xml/non-xml" as the primary differentiation.
I'd differentiate assets by asset types.
3. Content/Documents/Document and Content/Assets/Asset
I'm not quite sure what you mean here ... I would avoid this in
any case.
This makes it extremely easy to get all the Nodes of one Type, but
makes functions where the ContentType (or ResourceType) is irrelevant
much more difficult. If you want a list of the latest updates, you
need to search Documents and Assets separately and then merge the
lists and resort the result. A simple search for Resources that have
a new Revision ready but unpublished becomes difficult. And it adds a
Node that exists only to categorize other Nodes; I cannot think of
anything useful to add to these extra Nodes.
Fourth (repeating #2), regardless of how they are stored, programming
requires separate classes because too much functionality is different.
Identification, security, language support, workflow, and relations
can be handled by the superclass, but how they are used within Lenya
and how they are sent to visitors is very different.
IMO this functionality would be in the responsibility of the asset type.
The asset class itself is just a storage item.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
