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"?
It would be part of the API:
Document.addReference(Document, int referenceType)
Document.removeReference(Document)
Document.getReferences()
...
[...]
The more implementation options you want to give to the integrator,
the more difficult it will be to design a comprehensible and
maintainable framework.
it's not that complex. We already have everything, but we need to
abstractize it just as JCR is an API working on nodes and properties
instead working on directories and files ;-)
Yes - the Lenya API should support working on documents.
But a custom copier, deleter, ... would have to operate
"behind the scenes".
Another issue is the communication between components. You have
to find a "least common denominator" to design interfaces. If
you want to allow polymorphism for a family of components which
operate on the same data, you're likely to end up with the
MagicContainer antipattern (see the Creator interface). And IMO
a ParameterObject should not be used fo inter-component
communication.
can you give an example here as well?
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.
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.
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
...
If implementing a custom
resource type means to implement all these mentioned components,
it means to virtually implement a document management system for
each advanced and complex resource type.
yes, but what is the alternative?
IMO the reference concept is sufficient to fulfil the requirements
mentioned until now.
maybe it is, maybe it's not. My experience tells me that everytime one
thinks one has now covered all usecases, a new usecase pops up.
Off Topic: for instance I think the 1-to-1 mapping of "lenya meta files"
is not
sufficient as it is today, because for instance the usecase of dynamic
URLs, e.g.
the timestamp, or proxy requests are not covered, but can only be
covered by
allowing more general patters after the 1-to-1 mapping.
I don't quite understand this - could you please give an example?
And as said above I don't think that's a problem
because of the argument above. Also one can offer tools to simplify
the process, just as
for instance there are tools to create XML Schemas, etc.
Well, IMO the major problem is that it is much harder to achieve
stability and backwards compatibility when the API becomes more
complex.
as said, I don't think it's more complex, but less specific, whereas
in most problems maybe one specific implementation can be used.
I understand the difficulty to abstractize, because it took me for
instance a long
time to understand how specific polynomials can form a vector space:
http://en.wikipedia.org/wiki/Examples_of_vector_spaces
http://en.wikipedia.org/wiki/Vector_space
but recognizing it in the end will solve a lot of problems very quickly.
And I think recognizing the generic API and providing implementations
(as the by you mentioned reference implementation) will make things very
simple in the end.
OK, let's see where this thread leads us ...
-- 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]
