jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nandana Mihindukulasooriya" <nandana....@gmail.com>
Subject Web Apps on Jackrabbit - best practices
Date Sun, 24 Jun 2007 20:33:22 GMT
    As I was browsing through the mailing list (developer list) and found this
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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message