Michael Wechner wrote:
Andreas Hartmann wrote:
Michael Wechner wrote:
[...]
which I think should apply for all "components" working on resource
types:
Creator
Editor
Indexer
Publisher
LinkRewriter
....
If we allow this, we would also need a resource-type specific Mover,
Copier, Deleter, Deactivator, Revisioner, ...
similar to the source interface ;-)
It's not really similar. The source interface is a single entry point
to access resources using a protocol. There are no cross-connections
if you use the concept consequently (i.e., always use the protocol and
therefore the source implementation to access these resources)
The components mentioned by Josias have multiple cross-connections.
Providing a specific implementation for one of them requires to
provide implementations for the others as well.
I don't fully understand. Can you give an example?
Imagine a resource type which uses a binary source and an XML source
for a document.
If you allow this, you have to
- implement a Copier which copies these two files
- implement a Revisioner which backs up / restores these two files
- implement a Deleter which deletes these two files
- ...
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. You could maybe compare this with
the onParentVersion functionality of JCR.
[...]
But if we allow that a document may be "anything", and only the
resource
type knows what it is, the complexity seems to grow quite a lot (of
course the flexibility would increase, too). It might also lead to
duplication of knowledge if each resource type has e.g. its own
publisher.
you can always provide default implementations
But that doesn't reduce the complexity.
I think it does. In probably most cases you don't have to implement it
yourself
but pick an existing one
I didn't mean the complexity of a single implementation, but
the complexity of the API (I'm not sure what Josias meant).
The more implementation options you want to give to the integrator,
the more difficult it will be to design a comprehensible and
maintainable framework.
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.
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.
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.
-- 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]
