a belated reply (i'm a weekend worker atm) :(
Andreas Hartmann wrote:
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).
i'd still say "can consist". i.e. the language field in the asset
properties can be empty, in which case the asset is considered to be in
the default language.
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();
}
of course. but we have the concept of a "default language" for this,
i.e. if a requested language version does not exist, just return the
default one. the only modification necessary will be contained inside
getTranslation() and will be invisible to users, which is how it should be.
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).
ok. so it's just that some assets (namely the xml ones that solprovider
does not want to call assets) can reference other assets. sounds nice to me.
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.
no, of course not. but to reduce user confusion, it's nice to have this
term in the docs. the handling should be unified.
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.
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
