Michael Wechner wrote:
[...]
does this imply moving to flat storage,
well, it could be anything, whatever your "persistance manager" would
do ;-) but the important thing is that they
would never need to be changed ...
IMO it would imply flat storage (from an API point of view, the internal
storage could be a B-Tree or something like that for performance
reasons). The persistence layer shouldn't have to care about URL space
or site structure issues, otherwise SoC / software orthogonality would
be violated.
agreed. I just wanted to point out that it doesn't have to be flat and
it could
still be human readable depending how we want to implement it.
Yes, I see.
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).
----
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.
WDYT?
-- 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]
