I think a much better approach would be to come up with a
Repository.java
interface and a few implementations that I can choose when I install cocoon. This implementation would also implement Source.java and provide its functionality thru a URL protocol.
This allows:
- clear separation of concerns: cocoon should *NOT* be doing repository stuff, which is already big and complex enough
- complete IoC: you choose the implementation and the implementation decides what to do and how to do it. Your contract remains the same (thru the source-provided URL protocol and thru the component interface)
- transparent polymorphism: you can have different implementations of a repository... file system, webdav, CVS, JCR, ... without having to change any code in your application
Thoughts?
-- Stefano.
Looks good! However, I think some people may not need all 5 of your requirements:
> Functionality I need is: > > 1) open/save document > 2) create collection of documents
I think these are the core requirements of a repository. I also think a simple form of document retrieval (like a Source) is necessary, but that might just be rolled into "open"
> 3) attach metadata to documents (externally to them!!) > 4) query the repository against document metadata > 5) versioning (autoversioning on saving and version update)
Some people might like to get versioning and metadata a la carte. Not all versioned repositories need an external metadata facility or the ability to query it. I think all versioned repositories do need some metadata (commit logs, permissions, etc).
So what about a basic Repository interface, a specialization of it for metadata, and a specialization of that for versioning?
-- Ryan Hoegg ISIS Networks http://www.isisnetworks.net
