Le 09-11-16 à 13:12, Alexander Klimetschek a écrit :
2009/11/16 François Cassistat <[email protected]>:
I think JCR+OCM is perfect for rapid development.
Please explain: why should adding a code layer be more rapid?
I see this from a RAD and object database perspective.
OCM provides a sort of CRUD interface on objects. Defining an object
is simple and fast, then you specify the location and begin using it.
No need to worry about structures and everything. Maybe OCM have
limitations and is not optimal, but software is written fast and
easier to be changed. This is perfect for iterative development where
changes are likely to be asked.
I agree that the JCR layer might not cover all typical operations in
convenient methods, but you can provide helper methods for that (eg.
jackrabbit-jcr-commons) that make life easier but still only depend on
the JCR API.
It is true, but for me, if you generalize helper methods to the
extreme, you get something that looks like OCM anyway. Maybe you can
make something as complex and more flexible, and this could be a great
thing.
The only complexity it
adds is on performances, I found the code to be more readable with
OCM.
Maybe I do not have much experience with "low-level" JCR
programming, but
the problem with manipulating nodes is that you get all kind of
variables
which you never know how to name (parentNode, node, subNode[],
nodeToDelete,
newNode, etc.) and it becomes unreadable and when your code gets
bigger.
I guess in most cases utility methods, as mentioned above, will solve
this. In addition, suggesting you have a simple node = object mapping,
I don't see why you shouldn't get the same "complexity" of variable
names with your DAO entities. And nobody forces you to use "node" in
the variable name. Using scripting, property access becomes even
simpler (see Apache Sling, Javascript or the ValueMap from the sling
api). Only in Java the "getProperty()" way of reading properties might
be a bit cumbersome, but IMO nothing that is so bad that it should add
a new layer, dependencies and more code:
Node user = session.getRootNode().getNode("home/users/johndoe");
user.getProperty("name").getString();
....
Yes, like I said, I lack experience manipulating nodes (before I tried
JCR, I was using active records on my projects).
The problems I have with naming nodes variables are :
- If I made utility methods, you don't know how what the node is, your
variable get named "nodeThing" generally.
- When using a non-general method, you should already have something
like an User object named user and you end up calling your node
userNode because you don't know how to make the name distinct and easy
to read.
Anyway, I just wanted to say that working with nodes add a certain
complexity on your code because the code itself does not represent
visually the tree's hierarchy since it is flatten (as could XSLT could
be, by example). If you are working with many nodes on different
location and doNotWantNamesToBeThatLong, this gave me readability
problems.
I found myObject.save() to be straightforward and clean.
A problem with object.save() is often that you don't really know the
scope of the session/transaction. Explicit handling is better, eg. in
the context of webapps it's typically one session per request. JCR 2.0
goes fully onto this and deprecates Item.save() (albeit still
supported by Jackrabbit) and only allows a Session.save().
You are right.
A generalisation is never perfect, but when it fits for 95% of my
needs, I can afford making exception cases for the other 5%.
Regards,
Alex
--
Alexander Klimetschek
[email protected]
François
