incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandro Boehme (JIRA)" <j...@apache.org>
Subject [jira] Updated: (GRFT-34) An initial code base for the mapping project.
Date Sat, 09 Jul 2005 14:30:13 GMT
     [ 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


Mime
View raw message