jackrabbit-dev 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 app design pattern questions
Date Wed, 20 Jun 2007 13:25:32 GMT
> > > On 6/19/07, bilobag <bilobag@hotmail.com> wrote:
> > >> I am in the beginning stages of a web based CMS tool using JSF,
> Spring
> > >> and
> > >> Jackrabbit.

> > work directly with too many jcr method calls like
> > getProperty()/setProperty().  I definitely like the OCM tool, but i feel

IMO that's the point. In general I would tend to go with Jukka's suggestion
and use the JCR API as far as possible. But especially with JSF you can't
really use it. JSP + JSF EL aren't powerful enough to use
Node.getProperty("myProperty") or Iterators or things like that. So you have
to put something on top, wrappers around JCR objects or a business layer
that accesses the JCR API and provides and relatively plain getter/setter
API for your web pages.

Regards
Hendrik


> -----Original Message-----
> From: Martin Perez [mailto:mpermar@gmail.com]
> Sent: Wednesday, June 20, 2007 8:04 PM
> To: dev@jackrabbit.apache.org
> Subject: Re: Web app design pattern questions
> 
> IMHO, everything depends on the nature of your application. This remembers
> me the putting triggers/business logic/rules in your tables/db/stored
> procs.
> discussion. So there is many ways to do it and everything depends on how
> you
> plan to evolve your app.
> 
> Personally I find myself more comfortable writing an abstraction layer on
> top of JCR/JDBC/whatever just to act as a facade. In the past I manage to
> migrate from Hibernate to Jackrabbit almost seamlessly thanks to this
> business objects/interfaces layer, so I could change everything to
> Jackrabbit without touching the client apps. That business layer can also
> be
> worth to expose your interfaces through WS/REST/Any-fancy-word-here very
> easily. And of course, it will allow you in the future to migrate to any
> JCR
> alternative or better technology (hopefully ther won't be).
> 
> But I also can see the value on Jukka's words and in many cases will also
> make sense to go in that way, or even to choose an hybrid approach.
> 
> Regards,
> Martin
> 
> On 6/20/07, bilobag <bilobag@hotmail.com> wrote:
> >
> >
> > So you're saying that you use the actual node objects on the front
> > end?  My
> > motivation was that I was trying to make it easier for the front end
> > coders
> > to integrate the jackrabbit backend.  I thought if i used DTO's, the
> front
> > end coders could just call the setters/getters from the page and send
> the
> > object back to the business logic layer to be easily saved w/o having to
> > work directly with too many jcr method calls like
> > getProperty()/setProperty().  I definitely like the OCM tool, but i feel
> > that i should wait till its been stable for a little longer.  I was also
> > concerned that I could have some concurrent modification issues if i
> used
> > the nodes in the front end.  Any specific ideas or feelings about all
> > this?
> > Ideally I would like to make things easier for the front end by
> providing
> > methods to pass the form information to instead of having to repeat code
> > everywhere.  I'm just unsure what objects to use for the front
> > end...DTO's...nodes...wrapper classes?
> >
> >
> > Jukka Zitting wrote:
> > >
> > > Hi,
> > >
> > > On 6/19/07, bilobag <bilobag@hotmail.com> wrote:
> > >> I am in the beginning stages of a web based CMS tool using JSF,
> Spring
> > >> and
> > >> Jackrabbit.  Please give any design advice you may have for the
> > following
> > >> questions:
> > >
> > > Chiming in a bit late...
> > >
> > >> 1) I have 3 node types. Content, book, magazine.  Book and magazine
> > >> extend
> > >> the content type.  They all have some common properties and some
> > >> different
> > >> properties.  Now I first thought about creating wrapper classes that
> > just
> > >> wrap the Node object and provide getters/setters for any properties I
> > >> have
> > >> for each nodeType.  However, I am unsure if this is a good idea
> > possibly
> > >> because of locking and concurrency issues.  I don't know if its a
> > better
> > >> idea to have data transfer objects instead to move data to/from the
> > front
> > >> end.  However, its more work to have to copy the propertys to/from
> the
> > >> DTO
> > >> objects back into the node, but it could be the safer design.
> > >
> > > When possible I typically try to avoid extra layers on top of JCR.
> > > Unlike relational databases, JCR is actually quite "OO-friendly" so
> > > the need for an DAO/DTO layer is not that big. Typically such a layer
> > > just ends up limiting the available functionality.
> > >
> > > I'm not against the OCM tool as is, I think it is very useful when you
> > > already have an existing object model to be persisted, but if you get
> > > to start from scratch then I would rather recommend directly using
> > > JCR.
> > >
> > > My favourite way of working with JCR is to treat nodes as stateful
> > > resources, and my code as a set of stateless operations to be applied
> > > on those resources. Such an approach is very "web-friendly".
> > >
> > > BR,
> > >
> > > Jukka Zitting
> > >
> > >
> >
> > --
> > View this message in context:
> > http://www.nabble.com/Web-app-design-pattern-questions-
> tf3946577.html#a11212237
> > Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
> >
> >


Mime
View raw message