incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <s.boe...@inovex.de>
Subject Re: JCR integration proposal
Date Wed, 30 Mar 2005 13:54:22 GMT
Hello,

Oliver Kiessler wrote:
> hi sandro,
> 
> 
> I am not sure why "node type safety" is such an important issue.
Because if it turns out, that using node types for bean classes is the
wrong way it will be very hard to fix in our project. In comparison to 
that, API changes should not be a big problem.
I'am really looking forward to implement things, but first I need to
make sure, the basic idea is not wrong and I work in the right direction.
If necessary, I will collect the pro's and con's of our discussion and 
then finally ask for some kind of simple vote at the
jackrabbit mailing list (like no custom nodetypes/few custom
nodetypes/bean class=custom nodetype).
I checked your initial source code of the mapping. But as the example is 
using a custom nodetype I don't see any advantages for not using custom 
nodes.

> Whether I reflect on the node properties of an unstructured node or
> whether I reflect on a node type definition, does not make such a big
> difference to me. Am I missing something?
For me it would just be a redesigning of node types. The node type spec
would be redundant in every single node of the same type.

> I think custom node types are definately an issue to some extent but I
> am not sure if a new node type needs to created for every bean class
> type that needs to persisted. A base node type makes sense in my mind.
If you start having an own node type, you start being dependant on a
special JCR implementation. Because node type registration is not part
of the JCR spec. Having no custom node types at all, would surely make 
it easier to exchange JCR implementations. I'am not sure if it an added 
value to have something between. But I think you already know that.

Regards,

Sandro
> 
> regards,
> oliver
> 
> 


Mime
View raw message