[EMAIL PROTECTED] wrote:
Michael Ralston wrote:
I'm wondering why documentManager.create exists?
Hmmm - I can't find the method ...
Do you mean the interface o.a.lenya.cms.publication.DocumentManager?
Sorry, DocumentManagerImpl.create is method I meant
This method just copies xml from one sourceURI to another. What then are
you to do if your document is not xml, or not even stored in a file?
There's a create method in the DocumentManagerImpl, it is used by add().
But it copies arbitrary sources (not only XML) ...
In my instance, with the EJB repository I am working on, content is not
stored in a XML form, nor is it stored in any easily serializable form. It
is only stored as an Object.
OK, I see. The current architecture handles documents as containers
for arbitrary content which is accessed using streams. In a first step,
you would need a DocumentManager.add() method which doesn't initialize
the document's content, but IMO we should rather discuss the concept
independent from this implementation detail.
Should the method be removed and the document content create be moved
into the usecase? Then the developer can make a usecase implementation
for each of their document types.
At the moment, DocumentManager.add() creates a new document by using
the sample content provided by the resource type. Post-processing
of the created content should be handled by the usecase.
Would you mind giving an example what you mean? Thanks!
I've looked at the 'Proposal for an object model to support composed
documents and plugins' [1] and tried to implement some of the ideas there.
My node no longer stores any content. It is used as a way to associate
content components with a sourceURI.
I've made this association with the following objects:
- an abstract content object, which returns a DOM document (if an
inputSource is required this can be run through SourceUtil). This dom
document is also composed of child content objects.
Is this parent-child relation related to the site structure?
Or is it a kind of "part-of" relation / composition?
- an abstract relationship object, which has a reference to a content
object labelled 'child'
- an implementation of the abstract relationship which has a 'Node' parent
- an implementation of the abstract relationship which has a 'Content' parent
This relationship layer then allows me to have a heirarchy to my content.
For example, the main page of an image gallery could have a 'Gallery'
content object which is a parent to many 'Image' content objects.
Can't this be handled by the SiteManager component?
Or do you need a separation between URL space and content hierarchy?
When
clicks on the image, they are taken to the sourceURI which access the
Image content directly. A similar scenario could be imagined for a Message
board, with replies to messages being child 'Content' objects. I can also
have the same content on many different sourceURI.
So... in relation to creating initial content for a Document... I need to
initialise each different content object in a completely different way to
a simple copy sourceURI to sourceURI...
OK, this should be handled by the create usecase.
I've implemented some of what I have discussed here, but not all. Any
ideas would be appreciated. My employer has approved me to contribute my
code to lenya and I hope to provide patches and/or a tarball soon :)
Cool, that's good to know :)
-- Andreas
MichaelR
[1] http://wiki.apache.org/lenya/ProposalContentModel
--
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]