> > > On 6/19/07, bilobag <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> Sent: Wednesday, June 20, 2007 8:04 PM
> To: [email protected]
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
> >
> >
