[EMAIL PROTECTED] wrote:
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.
Thanks for clarifying this!
The current implementation uses "0001", "0002", etc., but there is no
reason not to use UUIDs in the future.
With UUIDs, the file names wouldn't be human readable, given that the
repository implementation uses one file per document and that files
are identified by their UUIDs. This is fine with me, since it's an
internal storage detail - what do the others think?
----
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.
Hmm, I don't understand this implication ...
In all three cases, the sitetree would return a UUID for a given URL.
The difference is only about how the framework accesses the repository
layer, isn't it?
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.
That would also be the case with (2) and (3). It's just about internal
storage, the API wouldn't be affected. Or am I missing something?
-- 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]
