Michael Wechner wrote:
Andreas Hartmann wrote:
Michael Wechner wrote:
[...]
If you use two Lenya documents, and use the (not yet existing)
reference mechanism to link from the primary document to the
secondary document, the internal Copier, Revisioner, and Deleter
components will be able to handle this just by following the
references if this is desired.
which I would consider a very helpful implementation, but it shouldn't
be confused with the API.
What do you mean with "confused with the API"?
that the implementatio is becoming the API
What do you mean with "implementation is becoming the API"?
Both ways are possible - either you design an API and build
an implementation, or you have a proven implementation and
extract an API from it ...
It would be part of the API:
Document.addReference(Document, int referenceType)
Document.removeReference(Document)
Document.getReferences()
that's exactly what I think shouldn't be. This "reference
implementation" shouldn't
be the API, but maby I misunderstand something completely ...
How could you tell Lenya about references if reference
handling is not part of the API? The API is the interface
to communicate with Lenya - everything you can do must
be exposed through the API.
[...]
Imagine you have a JCR-based repository implementation.
Then your Copier interface might look like this:
Copier.copy(Document src, Document dest, javax.jcr.Session session)
In a RDBMS-based implementation, it might look like this:
Copier.copy(Document src, Document dest, DBConnection conn)
In a file system based implementation, it might look like this:
Copier.copy(Document src, Document dest, File contentDir)
And so on.
that should be hidden by the (resource type) persistance manager
Sure, you can sum up the copying, versioning, ... into a
persistence manager interface, but that doesn't change anything
but terminology.
But if you want to export the Copier interface in the API,
you have to provide a generic parameter passing mechanism,
e.g. with a ParameterObject:
Copier.copy(Documetn src, Document dest, RepoInformation info)
That's not elegant at all.
I think it should be
Copier.copy(ResourceType src, ResourceType dest)
resp.
Copier.copy(ResourceTypeID src, ResourceTypeID dest)
??
Why do you want to copy resource *types*?
We're handling documents (resources), not resource types.
Or have I totally lost track? :)
BTW, this brings up another problem if we allow multiple repo
implementations:
If you want to allow custom Copiers, Revisioners etc. for different
resource types, you end up with (resource types) x (repo impls)
implementations, e.g. a
XhtmlJcrCopier
XhtmlFilesystemCopier
...
OdtJcrCopier
OdtFilesystemCopier
...
right, but I don't see a problem with it
Well, I wouldn't like it :)
What do the others think?
[...]
right now every URL needs a Lenya meta file (1-to-1 mapping), e.g.
calendar.html is being mapped to calendar/index_en.xml.meta
but what if you have a proxy resource type for instance
proxy/** --> proxy.meta (???)
any you don't know what URLs are actually being available, then a
wildcard rule help or
if you have URLs like
time/45654645656.html (time/**) ---> millis.meta
OK, thanks for explaining.
I guess that would need some new concepts in Lenya.
-- 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]
