Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <11212237.post@talk.nabble.com>
Date: Wed, 20 Jun 2007 05:30:01 -0700 (PDT)
From: bilobag <bilobag@hotmail.com>
To: dev@jackrabbit.apache.org
Subject: Re: Web app design pattern questions
In-Reply-To: <510143ac0706200116p55e003e0maf5c2d14a47ceb29@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <11195283.post@talk.nabble.com>
 <510143ac0706200116p55e003e0maf5c2d14a47ceb29@mail.gmail.com>


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.