[ http://issues.apache.org/jira/browse/GRFT-34?page=all ]
Sandro Boehme updated GRFT-34:
------------------------------
Attachment: src_folder.zip
Hello,
attached you find an initial code base for the mapping project. I would like to
reach
general consensus about some issues to be able to adopt some things before I
initially commit it. Please feel free to create new threads in the mailing list
for
different issues raised in this email.
Regarding general quality and quality of documentation:
Instead of improving the documentation until it's perfect, understandable by
everyone
and writing sentences that are grammatically and orthographically (not sure if
it's
written the right way ;-) ) perfect I decided to share it with you as it is.
Not only
regarding the documentation: I don't like to send work where I could not
finished think
about it, especially in such a public area. But it would take to much time to
synchronize
with you instead. At the other hand, the documentation should be good enough
for being
replacable when I should decide to go on a journey round the world for the next
year ;-).
Probably the best way to explore how things are working exactly is to debug
through the
NodeTypeRegistration and the PersistanceManagerTest.
Current mapping semantics:
JCR nodetype <==> Java class
JCR child node <==> Java method
JCR value <==> The class of the returning object of a Java method. The
registered atomic
types should care about the conversion of classes and values.
Required primary types:
A Childnode Definition does not have only one type like a return type of a Java
method.
Instead it has a list of required primary types.
I interpret it like this:
If you have a Java method signiture that returns "java.lang.Object", then the
RequiredPrimaryTypes is the list of Java classes / node types that are allowed
to be
returned _at_runtime_.
I don't have an idea at the moment how to ensure the integrety for this at
runtime without
introducing performance problems.
The attached zip file contains the following components:
The mapping model
A node type registration component for Jackrabbit
Components for the persistence:
o atomic type converter
o object to item converter
Changing of nodetypes which are used by nodes:
As we map Java semantics to node type semantics, it would be nice for the
continuous
integration that we can reregister nodetypes when Java classes are changing.
But at the moment changing of nodetypes which are used by nodes is not yet
implemented.
I guess it is very hard to implement. But I will ask for an opinion on this at
the
Jackrabbit mailing list.
At the moment I delete the complete repository in order to test the node type
registration.
Some unsorted notes/questions:
o We need to add exception handling to the code base.
o We need to support for Collections and Interfaces.
o Maybe it makes sense to improve the design of the object
to item converter and the jackrabbit node type registration
by seperating the adapter classes from the recusive traversal.
o Is checkstyle applied to the code when I commit files so
I don't need to deal with the Apache code formatting and
the Apache license in my IDE (btw: it's Eclipse)?
Especially for the classes generated by JAXB it would be
good to know, that I don't need to add the licence with
a regular expression.
Source code decoration:
The mapping model is specified with an XML file. The definition of one
mapping can
be quite big, when you need to type all informations in the file by yourself.
It
would also be very error prone for typos.
At the moment it would at least be really helpful for creating testcases to
have
some sort of source code decoration with annotations or with XDoclet. As the
Java
source code already contains the Java part of the mapping definition, you
would only
need to decorate the classes or methods with node type information and we
have a
complete mapping definition for creating the according mapping XML-file.
Later I could imagine to also support MDD to create the mapping XML-file out
of a model
of a higher level.
Some quick ideas about use cases:
In my opinion, if I don't ignore something, the mapping project can also be
useful
for CMS's that don't want to change very much of their domain model and instead
want to use our mapping to adopt their classes to nodetypes.
I guess the Jackrabbit WebDav server uses specific node types (I did not check
it).
So I think it should also be possible to use these node types and adopt them
to an application domain model. This should make it easy to use the WebDav
protocoll with an undependent application domain model.
Things to discuss:
Hi Oliver, the dynamic repository creation and the update of the Jackrabbit
version was really helpful for implementing the basic version. This was not yet
the thing to discuss ;-).
Please feel free to tell me how I can adopt my registration component to fit to
your ideas of the CustomNodeTypeCreator.
The JCRSession seems to aim the same goal of the persistence manager. The reason
why I called it "Persistence Manager" was simply to make it clear that the
functionality of the class is, to persist objects (insert to repository,
get from repository, search in repository,...). But I'm open to rename it.
In the attached initial codebase you can specify the namespaces of the
application domain model in the mapping model's xml file. Different node types
can have different namespaces there. This is why I register the namespaces
within
the node type registration component. Your JCRSession also contains namespace
registration, this is why I want to ask you, if my handling is ok from your
point
of view.
Atomic types vs. custom node type converter:
Hello Christophe, initially you had the idea of custom node type converter. I
think the
basic idea was to give users the freedom of having their own conversion.
I think the atomic type converters in the current codebase what you wanted to
archive
with the custom node type converter. Please tell me if you had other things in
mind.
The atomic types should also be able to handle a little bit more complex Java
types.
Testcases:
We can use adopted TCK testcases to test if we pass through all functionalities
of the JCR. This would save us much time in comparison to test all JCR
functionalities from the scratch.
Projectname:
As Christophe already mentioned, it would be nice to have a cool project name.
Personally I don't have an idea, maybe an animal that has something to do
with any kind of "mapping" ;-) ?
JAXB:
In case you need it, the JAXB command I call in a script file is:
xjc -classpath
C:\SoftwareDevelopment\eclipseworkspace\jcr-mapping\target\classes
-p org.apache.portals.graffito.jcr.testmodel
-d C:\SoftwareDevelopment\eclipseworkspace\jcr-mapping\src\java
-p org.apache.portals.graffito.jcr.mappingmodel.nodetypeschema
custom_nodetypesV2.xsd
Finally, what do you think about all that?
Best regards,
Sandro
> An initial code base for the mapping project.
> ---------------------------------------------
>
> Key: GRFT-34
> URL: http://issues.apache.org/jira/browse/GRFT-34
> Project: Graffito
> Type: New Feature
> Reporter: Sandro Boehme
> Assignee: Sandro Boehme
> Attachments: jaxb_libs.zip, src_folder.zip
>
> As the list does not allow attachments I upload the zip file to this issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
