Web Apps on Jackrabbit - best practices

[Nandana Mihindukulasooriya <na...@gmail.com>]

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.

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.

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

Thanks,
Nandana

Re: Web Apps on Jackrabbit - best practices

[Nandana Mihindukulasooriya <na...@gmail.com>]

Hi Hendrik,
      Thank you very much for the comments.

> 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:
>
> http://www.mail-archive.com/dev@jackrabbit.apache.org/msg06212.html
>
>         yes ,  that is what I was trying to tell but a *not* was missing
by mistake. Sorry
I should have double checked it before sending to the list. Thanks once
again and I will
update the wiki with your comments in mind.

Regards,
Nandana

RE: Web Apps on Jackrabbit - best practices

["Hendrik Beck (camunda)" <he...@camunda.com>]

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:

http://www.mail-archive.com/dev@jackrabbit.apache.org/msg06212.html


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


Cheers,
Hendrik