Hi Andreas,
This block is really in an very early stage of development.
In the actually committed version, it does not work as expected.
Sylvain first wrote this JCRNodeSource for my own needs (I am one of his
coworkers) and I've applied many many patches to it without contributing
them back to Cocoon. I obviously apologize for that :-)
With this introduction beeing made, I'll try to answer your questions :
Andreas Hartmann a écrit :
Hi Cocoon devs,
I'm currently examining the JCR block (thanks, Sylvain, Michi and all
others
who were involved!)
Some questions:
1) IIUC, every time a source is resolved a new JCR session is created.
Does this mean that no transactions can be used?
Maybe it would make sense to attach the JCR session to the Cocoon
session, so that all resolved JCRNodeSources save their data to a
single session which would allow them to take part in a single
transaction?
There are many points here : some may wants to attach to the JCR Session
to the Servlet Session, others will want to attach JCR Session to the
Request (as a JDBC Connection, this is my case), others will want to
have one single JCR Session for the entire application.
This IMHO must be a configurable thing.
Other problem is the logout one : when called, the repository.login()
is made by the JCR block classes, but the logout must be made by the
application. But when ? I choose to implement this via Servlet's
RequestListeners or SessionListeners. You may also extend the
CocoonServlet to logout at the end of the service() method.
2) How about storing additional custom properties (e.g., meta data)
in the node which is represented by the source?
good point :-)
The JCRNodeSource is actually made for Nodes :-)
This idea was to also have a JCRPropertySource. But it has never been
implemented.
3) How about locking and versioning?
Another good point.
At the begining of my JCR-related work, I wanted to have
VersionedSource, LockableSource, and then
LockableModifiableTraversableVersionableSource :-p
And I then realized that such business logic things may overrun the goal
of Sources.
So I finally simply get the JCR Node from the JCRNodeSource and directly
play with JCR API in my own business logic classes.
Sylvain and I have actually had different ideas about what a JCRSource
must be.
I personally thought about an entry point to every JCR Item in the
Repository (it appears it is what you want too)
Sylvain thought more about a TraversableSource with directories and
files (actually nt:directory and nt:file Nodes).
I would be interested to known your usecases.
Regards,
Cédric
--
Cédric Damioli
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com
