You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Michael Ralston <mi...@ralston.id.au> on 2006/05/30 03:24:37 UTC

why should documentManager.create?

I'm wondering why documentManager.create exists?

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?

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.

MichaelR

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Object-XML-mapping (was: Re: why should documentManager.create?)

Posted by Andreas Hartmann <an...@apache.org>.
Michael Ralston wrote:
> Andreas Hartmann wrote:
>> michael@ralston.id.au wrote:
>>> 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.
> My content objects currently implement Cloneable, in order to provide 
> versioning. When I checkout a Node, I make a Clone of its Content object 
> so I can rollback.
> 
> I was thinking I could use this Cloneing to make Content object 
> templates for each ResourceType and then Clone them when I create a new 
> Node.

That sounds very useful.

BTW, how do your content objects provide their content to Cocoon pipelines?
And how is the object mapped to XML? If you're interested in synergies -
a friend of mine developed an object-to-xml-mapping concept in his diploma
thesis, he is also familiar with Lenya. I'm CCing him in this mail.
His contact data are here: http://metzner.org/home/


>>> 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.
>> I've looked at the 'Proposal for an object model to support composed
>>
>> Is this parent-child relation related to the site structure?
>> Or is it a kind of "part-of" relation / composition?
>>
> It's not necessarily related to the site structure at all (although it 
> can be). It's definetly a composition. Eg, if I have a 'News' content 
> object, then I could assign it to a cell on the right hand side of every 
> page, but it may not exist anywhere in the SiteTree or have a sourceURI 
> pointing directly to it.

OK, I see.


>>> 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?

> Yes, I want a separation between URL space and content. Then I can also 
> share content objects on different URLs.

That's a good point.

BTW, IMO it would be nice to see the javadocs of your approach to get
an overview. Is it easy for you to publish them somewhere?

-- Andreas

-- 
Andreas Hartmann
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
andreas.hartmann@wyona.com                     andreas@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: why should documentManager.create?

Posted by Michael Ralston <mi...@ralston.id.au>.
Andreas Hartmann wrote:
> michael@ralston.id.au wrote:
>> 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.
My content objects currently implement Cloneable, in order to provide 
versioning. When I checkout a Node, I make a Clone of its Content object 
so I can rollback.

I was thinking I could use this Cloneing to make Content object 
templates for each ResourceType and then Clone them when I create a new 
Node.

>> 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.
> I've looked at the 'Proposal for an object model to support composed
>
> Is this parent-child relation related to the site structure?
> Or is it a kind of "part-of" relation / composition?
>
It's not necessarily related to the site structure at all (although it 
can be). It's definetly a composition. Eg, if I have a 'News' content 
object, then I could assign it to a cell on the right hand side of every 
page, but it may not exist anywhere in the SiteTree or have a sourceURI 
pointing directly to it.

>> 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?
Yes, I want a separation between URL space and content. Then I can also 
share content objects on different URLs.

Thanks for your feedback!

MichaelR

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: why should documentManager.create?

Posted by Andreas Hartmann <an...@apache.org>.
michael@ralston.id.au 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
andreas.hartmann@wyona.com                     andreas@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: why should documentManager.create?

Posted by mi...@ralston.id.au.
> 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.

>
>> 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.
- 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. 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...

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 :)

MichaelR

[1] http://wiki.apache.org/lenya/ProposalContentModel


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: why should documentManager.create?

Posted by Andreas Hartmann <an...@apache.org>.
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?


> 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) ...


> 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!

-- Andreas


-- 
Andreas Hartmann
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
andreas.hartmann@wyona.com                     andreas@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org