Joern Nettingsmeier wrote:
[...]
<quote>
- - - Document (an abstract container for all assets)
contains:
- - - - Assets (text assets (in several languages), images, media files,
pdfs, etc)
Assets have revision control information.
Documents have a revision control information summary (the collection of
all current revisions of their assets). Whenever one asset changes, the
Document revision number is bumped.
</quote>
one thing that's missing is that all assets can have a language attribute.
asset:: An atomic piece of information, handled as a single unit by the
API.
An asset consists of multiple translations (language versions).
"can consist"?
From a user's point of view, it certainly makes sense to have non-localized
assets. Well, sand or water might look the same in all cultures (I don't
want to start a philosophical discussion here).
From a developer's point of view, I try to avoid optional features unless
they are absolutely necessary. It might be considered to return the same
content for all translations. getTranslations() would return an array
containing translations for all languages supported by the publication.
I just want to avoid code like this:
if (asset.isLocalized()) {
return asset.getTranslation(getLanguage());
}
else {
return asset.getUniversalTranslation();
}
document:: A dynamically assembled piece of information, based on an asset.
ok, i realize that not all assets are created equal. one is the starting
point which references the others. but the starting asset should not be
special. the document should know which is the starting asset of a
particular language version.
You request an asset. The document comes into existence automatically
by resolving the asset's references and including their content (or
parts of their content, meta data, you name it).
The document isgenerated by resolving references to other assets
and external resources. [1]
page:: The aggregation of 1..n documents + presentation.
[1] Using this definition, navigation widgets can be implemented as
documents,
based on an asset which references the resource which generates the
navigation
widget. This means, according to this definition, a page can contain
navigation
widgets as well.
hmm. for components such as navigation, how about "dynamic asset"?
Yes, that would describe it. But I don't see a need for a special handling.
The asset would for instance just look like this:
<ci:include src="cocoon://modules/sitetree/tree.xml?view=list-titles"/>
i'd
like the document to be the final piece of content that is created to
answer a user request.
Probably this is more appropriate, since it won't be possible to expand
the references first and apply a style later on.
-- 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]
