Let's give the choice to the user framework to use or not (custom) node
types.
Christophe
Sandro B�hme wrote:
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
