On 6/7/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
 From my point of view, the repository layer knows only about UUIDs.
If we want to allow human-readable storage, that would mean that
the UUIDs have to be human-readable. When a document is created, the
user would enter an (optional?) UUID string (if it is omitted, the
system chooses one).

http://en.wikipedia.org/wiki/UUID
UUIDs are 16-byte numbers.  Titles are human-readable.  In Lenya1.3,
the unique key to each Resource is referred to as a UNID (Unique
Identifier).  A UNID can be any String acceptable as a directory name.
The current implementation uses "0001", "0002", etc., but there is no
reason not to use UUIDs in the future.

----
Another question: How should languages be handled? Some options:
1. The repository layer knows about languages (i.e., a storage item
    is identified by a combination of UUID and language).

2. The repository layer UUID is a combination of CMS UUID and
    language (e.g., news + de -> news_de).

3. UUIDs and languages are not combined, i.e. every translation
    is identified by its own UUID or the language is part of the UUID.
    This would either lead to redundance (if the language is stored
    in the meta data additionally) or convention regarding the syntax
    of the UUID, so that language queries can be done.

IMO option (1) is the most reasonable, I see no need for abstracting
from the language in the repository layer.

Lenya is language-aware.  #2 and #3 make that very difficult because
different sitetrees are needed for each language.  While Lenya1.3
makes that possible (you can have as many structures as you want, and
they could be language-specific), it makes the expected case of the
same structure for all languages very difficult.

#1 is already implemented.  Resources have Translations.  Some
Resources (such as a language-independent graphic) have a
"defaultlanguage" for when no Translation exists for the current
language.

solprovider

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to