jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From François Cassistat...@maya-systems.com>
Subject Re: David's Model question : nt:unstructured and SNS
Date Mon, 16 Nov 2009 18:58:03 GMT

Le 09-11-16 à 13:12, Alexander Klimetschek a écrit :

> 2009/11/16 François Cassistat <f@maya-systems.com>:
>> 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  

>> 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  

>> 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
> alexander.klimetschek@day.com


View raw message