jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hendrik Beck \(camunda\)" <hendrik.b...@camunda.com>
Subject RE: Web Apps on Jackrabbit - best practices
Date Mon, 25 Jun 2007 08:26:37 GMT
Hi Nandana,

Some comments inside...

> -----Original Message-----
> From: Nandana Mihindukulasooriya [mailto:nandana.cse@gmail.com]
> Sent: Monday, June 25, 2007 3:33 AM
> To: users@jackrabbit.apache.org
> Subject: Web Apps on Jackrabbit - best practices
> Hi,
>     As I was browsing through the mailing list (developer list) and found
> this
> thread<http://mail-archives.apache.org/mod_mbox/jackrabbit-
> dev/200706.mbox/browser>about
> the best practices in building web apps on top of Jackrabbit. It was
> about how to access the data in front end and how to persist data. I would
> like to summarize those discussions and publish them on my
> jackrabbit-jcr-demo project wiki. So new comer to jackrabbit can easily
> read
> those summaries and get started.
>     I would really thankful if you can comment on the summaries and
> correct
> if I have got something wrong.
> Accessing and persisting data from the front-end
> Use nodes directly from the front end
> Here we treat nodes as stateful resources, and do stateless operations on
> them. So we directly modify the nodes from front end. Advantage of this
> approach is that we can use full functionalities of JCR. This would
> increase
> the performance also as we are not coping data to copying data and
> creating
> additional business objects. Disadvantages are that front end coders will
> also have to know about the JCR API rather than using getters/setters. And
> also there may be a possibility that a technology used in the front end is
> powerful enough to manipulate JCR API.

Shouldn't that rather mean "...that a technology used in the front end is
__NOT__ powerful enough..."? You could refer to JSF as a popular example for
that. Also, you can take this recent discussion into account:


And you say that "coders" will "also have to know about the JCR API". Think
about that they would only have to learn about JCR for being able to access
all kinds of data stored within a JCR. Not that I want to encourage this
approach in general, but imagine: if everybody would use this approach for
its front ends then the coders would only have to learn this one single API
to access all kinds of content stored within a JCR. It's actually one
advantage of a standardized API. 

> Use business objects and delegate the persisting to jackrabbit-ocm
> Here we work with business objects and delegate the access to JCR content
> to
> the jackrabbit-ocm framework. We can work with POJOs and jackrabbit-ocm
> will
> persist them on JCR repository. Anyway we have to pre-configure the
> mapping
> between data bjects and Nodes in a mapping file. This will easy for the
> application programmers and make application layer independent of
> persistence Layer.
> Wrap the nodes inside Wrapper classes
> This won't be a good option as it we can do the same in a much easier way
> using jackrabbit-ocm.

Uhm, I would say at least for use cases, where you need generic access to
the repository (i.e. where a business interface is NOT applicable) Wrappers
can still make it work. 

So IMO there might be cases where it's a option. And at least it shouldn't
be compared like that with OCM, the intentions of both differ a little bit.
OCM provides persistence for (existing) business objects, the wrappers would
extend the functionality of the JCR API.

> you can find my projects wiki page regarding this
> here<http://code.google.com/p/jackrabbit-jcr-
> demo/wiki/AccesingContentFromFrontEnd>
> .
> Thanks,
> Nandana


View raw message