You are viewing a plain text version of this content. The canonical link for it is here.

Posted to graffito-dev@incubator.apache.org by Costin Leau <co...@gmail.com> on 2005/10/04 14:07:59 UTC

Re[2]: [jcr-mapping] converter design

Hello Christophe,

Tuesday, October 4, 2005, 4:47:06 PM, you wrote:

On 10/4/05, Costin Leau <co...@gmail.com> wrote:

Hello again.

I'd like to open another issue: the converters.

1. There is no Converter interface - this is one package where an

interface is BADLY needed

There 3 kind of converters :

* ObjectConverter : convert a pojo object or bean fields

* AtomicTypeConverter : convert simple types

* CollectionConverter : a complete collection with different mapping style (there 2 implementation but you can defined your own)

Some refactoring is required here. Only CollectionConverter is interface based (until now).

2. AbstarctAtomicTypeConverter should be AbstractAtomicTypeConverter

absTARCT should be absTRACT.

4. the methods on the AtomicConverter and the converter concept and

plugability are contradictory. The atomic converter specifies through

the getJavaTypes what classes it should be used for the

getJcrValueFromJavaObject specifies that " The mapping framework

ensures, that only objects of the types returned by getJavaTypes are

forwarded to this method."

This means in short that the converters can't be used for other types

other then the ones they have been design for.

For example if I want to use the Date converter on an object that has

the same contract, even though I am register it manually it will not

work.

The converter should do the conversion and that's it - it's the

framework job to do the rest especially if it forces the developer to

supply the map of converters. Basically you have to write code in two

parts to do the same thing.

getJavaTypes can be dropped, it is not used now.

I don't understand you, the converter makes conversions and that's all.

Yes but the java types method add extra functionality like I said and you also should not be

the converter problem.

Christophe

Best regards,

Costin mailto:costin.leau@gmail.com

Re: Link

Posted by Christophe Lombart <ch...@gmail.com>.

On 10/5/05, David Sean Taylor <da...@bluesunrise.com> wrote:
>
> Christophe Lombart wrote:
> > David,
> >
> > Here is the model :
> http://incubator.apache.org/graffito/class-diagrams.html
> > Link extends CmsObject by this way, you can create links on folder,
> content,
> > ...
> >
> > The contentModelService manages links.
>
> But, Folder has a collection of Contents
>
> public List getContents();
>
> The javadocs don't explicity say what kind of obects are returned from
> getContents();
>
> /**
> * Get the folder contents.
> * @return a List of content which are located into this folder.
> */
>
> But since you use the word "content" i was assuming it was Content.

Content can be binaries associated to a content type (the interface is
Document : see the dm pck).
But Content will later other descendant like news, article, post in a forum
app, ...
Thoses content are not aossociated to a binary content but more to severals
fields like paragraph, descritption, ...

Links are not Content, they are CmsObject

By this way, we can also link folders.

Re: Link

Posted by David Sean Taylor <da...@bluesunrise.com>.

Christophe Lombart wrote:
> David,
> 
> Here is the model : http://incubator.apache.org/graffito/class-diagrams.html
> Link extends CmsObject by this way, you can create links on folder, content,
> ...
> 
> The contentModelService manages links.

But, Folder has a collection of Contents

	public List getContents();

The javadocs don't explicity say what kind of obects are returned from 
getContents();

	/**
	 * Get the folder contents.
	 * @return a List of content which are located into this folder.
	 */

But since you use the word "content" i was assuming it was Content.
Links are not Content, they are CmsObject



-- 
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194

Re: Link

Posted by Christophe Lombart <ch...@gmail.com>.

David,

Here is the model : http://incubator.apache.org/graffito/class-diagrams.html
Link extends CmsObject by this way, you can create links on folder, content,
...

The contentModelService manages links.

Christophe


On 10/5/05, David Sean Taylor <da...@bluesunrise.com> wrote:
>
> Hi Christophe,
>
> In the older versions of Graffito/JCMS that I am (still (sigh)) using,
> links exist in folders. I can't see how thats modeled in the SVN head.
>
> Folders have contents and folders have more folders.
> Im proposing folders having links, and either:
>
> Link extend Content instead of CmsObject
>
> -- or --
>
> add method to Folder
>
> getLinks()
>
> Thanks,
>
> David
>
>

Link

Posted by David Sean Taylor <da...@bluesunrise.com>.

Hi Christophe,

In the older versions of Graffito/JCMS that I am (still (sigh)) using, 
links exist in folders. I can't see how thats modeled in the SVN head.

Folders have contents and folders have more folders.
Im proposing folders having links, and either:

Link extend Content instead of CmsObject

-- or --

add method to Folder

getLinks()

Thanks,

David