Hello,
Oliver Kiessler wrote:
Because if it turns out, that using node types for bean classes is thehi sandro,
I am not sure why "node type safety" is such an important issue.
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.
If you start having an own node type, you start being dependant on aI 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.
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
