Hi Oliver,
from all I know only defining, creating and managing of node types is not part of the specification. So you are right, registering of nodetypes in the repository is specific for every repository. But once I have the nodetypes - reading, introspection and writing should be similar in every repository implementation. Nobody should need to change the code for the runtime classes of an application if the implementation of the JCR was changed. Only the registration of the nodetypes at design time would be different. Or do I miss something here?
> I think that a JDO approach is beyond the scope and capabilities of
> JCR and was not meant for it.
Of course it is beyond the scope. But I think it would be useful in a real live application anyway.
regards,
Sandro
Oliver Kiessler wrote:
hi sandro,
Would that mean, you will have a nodetype for each class? How do you plan to organize the JCR-nodes?
Definition and configuration of nodetypes is up to the jcr
implementation. It might be implemented by jackrabbit but not by
others. This might leave you with a repository that is unusable with
other cms/jcr implementations. Jcr's main benefit was to create a
common (shared and compatible) infrastructure for content management
systems, with this approach you will probably loose it.
Let's not forget that node type configuration and management is up to
the jcr repository implementation, not necessarily to the jcr capable
repository client implementation.
What's your opinion on that? Are you interested in a general, JDO supporting solution or do you need an immediate Graffito specific solution? As I don't want to slow down your work with a general solution I can work parallel on a JDO and node type based solution and later contribute it if you need it. Whats your opinion on that?
I think that a JDO approach is beyond the scope and capabilities of JCR and was not meant for it. But I might be wrong... ;)
regards, oliver
