You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by bilobag <bi...@hotmail.com> on 2007/06/19 15:56:22 UTC
Web app design pattern questions
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:
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.
2) When adding a node, if I use my node wrapper classes, I will call
addNode() on the parent and wrap the child node. Then forward to the form
page where the node data is entered...then call save(). The only issue is
that when you call addNode, you need to specify the path/name of the node.
I will not have this information until after the user submits the form.
First, how important is the path/name of the node? To me it seems like it
should always be unique amongst nodes with the same parent. Second, this
goes back to my first question where i'm not sure whether to use DTO's or
node wrapper classes. If i use DTO's, adding won't be an issue. Please
give any design advice you may have. Thanks.
--
View this message in context: http://www.nabble.com/Web-app-design-pattern-questions-tf3946577.html#a11195283
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Web app design pattern questions
Posted by Christophe Lombart <ch...@gmail.com>.
> 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.
Personally, I think JCR is an excellent choice for the persistence layer
but not in the business services and presentation layer.
Building business logic with "business" objects is less verbose and more
easy to maintain. Furthermore, it is always interesting to make abstraction
on the technology to use in the persistent layer. A lot of web design
patterns used for DB web app can be used also for JCR web app.
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".
When a remote JCR server is used, what about a JCR session pool (in each web
apps accessing the JCR server) and a complete stateless situation ? I would
like to test this kind of situation with Jackrabbit.
Re: Web app design pattern questions
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 6/20/07, Felix Meschberger <Fe...@day.com> wrote:
> And by the way, using an OCM with proper objects also helps a lot ensuring
> the integrity of the data managed, as there is a single point of control
> regarding how the data is accessed. Again, your mileage may vary, but as
> code tends to grow, this should be seriously considered.
This is actually one of the points why I prefer *not* to use an object
layer on top of JCR. Having our content in a repository allows it to
be easily accessed and modified by a number of different and
independent tools. Hiding your integrity constraints in an object
layer makes that object layer the only "safe" way to access the
underlying content, which is bad for extensibility of the system as a
whole.
I would much rather put integrity and other constraints inside the
repository using the node type mechanisms. Unfortunately the current
set of constraints available in Jackrabbit is somewhat limited, but
that's a good case for filing improvement requests instead of
implementing extra constraints in application code.
BR,
Jukka Zitting
Re: Web app design pattern questions
Posted by Felix Meschberger <Fe...@day.com>.
Hi,
Well, your mileage may vary :-)
In my experience, JCR is a wonderful and easy API to use. Still having
proper Java Objects to work on and to delegate loading and unloading to an
OCM layer helps me a lot - in terms of typing, fail safeness and not having
to worry about checked exceptions which are not thrown in most cases anyway.
And by the way, using an OCM with proper objects also helps a lot ensuring
the integrity of the data managed, as there is a single point of control
regarding how the data is accessed. Again, your mileage may vary, but as
code tends to grow, this should be seriously considered.
Regards
Felix
On 6/20/07, Jukka Zitting <ju...@gmail.com> wrote:
>
> Hi,
>
> On 6/19/07, bilobag <bi...@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
>
Re: Web app design pattern questions
Posted by bilobag <bi...@hotmail.com>.
Thanks for all the input. I think for now i will just go with the DTO
pattern. However, I would like to possibly use a generic class for the
dto's like the LazyDynaBean. Has anyone had any experience using this on
the front end with JSF? Maybe this belongs in a different forum...
Christophe Lombart wrote:
>
> It should be nice to collect the different JCR/Jackrabbit experiences and
> make a JCR design pattern catalog (web, simple app, ...).
> Maybe in the wiki ? It will take a lot of time but we can start with small
> pieces of info and when someone want to share its experience, it can add
> more info in this catalog. If we have different point of view, it will
> also
> help to compare the different solutions.
>
> br,
> Christophe
>
>
> On 6/20/07, Jukka Zitting <ju...@gmail.com> wrote:
>>
>> Hi,
>>
>> On 6/20/07, Hendrik Beck (camunda) <he...@camunda.com> wrote:
>> > > > 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.
>>
>> This is actually something I'd like to see OCM to help with. There was
>> brief related discussion on the Graffito mailing list a few months
>> ago, see especially:
>>
>> http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200702.mbox/%3c510143ac0702140601x54f50bedk1e09d2af133b0ec2@mail.gmail.com%3e
>>
>> BR,
>>
>> Jukka Zitting
>>
>
>
--
View this message in context: http://www.nabble.com/Web-app-design-pattern-questions-tf3946577.html#a11253667
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Web app design pattern questions
Posted by Christophe Lombart <ch...@gmail.com>.
It should be nice to collect the different JCR/Jackrabbit experiences and
make a JCR design pattern catalog (web, simple app, ...).
Maybe in the wiki ? It will take a lot of time but we can start with small
pieces of info and when someone want to share its experience, it can add
more info in this catalog. If we have different point of view, it will also
help to compare the different solutions.
br,
Christophe
On 6/20/07, Jukka Zitting <ju...@gmail.com> wrote:
>
> Hi,
>
> On 6/20/07, Hendrik Beck (camunda) <he...@camunda.com> wrote:
> > > > 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.
>
> This is actually something I'd like to see OCM to help with. There was
> brief related discussion on the Graffito mailing list a few months
> ago, see especially:
>
> http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200702.mbox/%3c510143ac0702140601x54f50bedk1e09d2af133b0ec2@mail.gmail.com%3e
>
> BR,
>
> Jukka Zitting
>
Re: Web app design pattern questions
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 6/20/07, Hendrik Beck (camunda) <he...@camunda.com> wrote:
> > > 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.
This is actually something I'd like to see OCM to help with. There was
brief related discussion on the Graffito mailing list a few months
ago, see especially:
http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200702.mbox/%3c510143ac0702140601x54f50bedk1e09d2af133b0ec2@mail.gmail.com%3e
BR,
Jukka Zitting
RE: Web app design pattern questions
Posted by "Hendrik Beck (camunda)" <he...@camunda.com>.
> > > On 6/19/07, bilobag <bi...@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 <bi...@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 <bi...@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.
> >
> >
Re: Web app design pattern questions
Posted by Martin Perez <mp...@gmail.com>.
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 <bi...@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 <bi...@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.
>
>
Re: Web app design pattern questions
Posted by bilobag <bi...@hotmail.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 <bi...@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.
Re: Web app design pattern questions
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 6/19/07, bilobag <bi...@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
Re: Web app design pattern questions
Posted by Christophe Lombart <ch...@gmail.com>.
On 6/19/07, bilobag <bi...@hotmail.com> wrote:
>
>
> Thanks for the quick responses. I am interested in trying the mapping
> tool.
> I am currently using Spring and noticed that you are working on some
> spring
> integration components. Are these in a stable state? I would like to be
> able to configure the jcr mapping file in my spring configuration to load
> at
> startup. Please let me know if there is anything that currently does
> this.
> Thanks.
We made a lot of changes in the OCM API. So, we have to review the Spring
support.
I would like to modify it when the first OCM release is done.
Pavel Konnikov wrote:
> >
> > On Tue, 19 Jun 2007 18:52:00 +0400, Christophe Lombart
> > <ch...@gmail.com> wrote:
> >
> >>> Also, is there any documentation for getting started with this?
> >>
> >> I would like to work on the doc asap but they are some interresting
> info
> >> in
> >> the doc folder. You can generate it with maven. Anyway, I have to
> >> review it
> >> due to a lot of changes since the move into Jackrabbit.
> >>
> > In documentation generated by maven missing pictures and on page "The
> > Persistence Manager Setup" very old information.
> >
> > setup now more simple:
> >
> > ...
> >
> >
> > session.getWorkspace().getNamespaceRegistry().registerNamespace("ocm",
> > "http://jackrabbit.apache.org/ocm");
> >
> > String[] files = {"mapping1.xml", "mapping2.xml"};
> > ObjectContentManager objectContentManager = new
> > ObjectContentManagerImpl(session, files);
> >
> > // register namespace "ocm" and nodetypes from
> > src/test/test-config/nodetypes/custom_nodetypes.xml
> >
> > MyObject object = new MyObject();
> > object.set...();
> > object.setPath("/some/path");
> >
> > objectContentManager.insert(object);
> >
> > object = (MyObject) objectContentManager.getObject
> ("/some/path");
> > objectContentManager.update();
> >
> > Filter filter =
> > objectContentManager.getQueryManager().createFilter(MyObject.class);
> > Query query =
> > objectContentManager.getQueryManager().createQuery(filter);
> > objectContentManager.remove(object);
> >
> > objectContentManager.save();
> >
> > ...
> >
> > It is very simple!
> >
> >>> So the wrapper class design isn't a good idea?
> >>
> >> not for me :-) maybe others can have another point of view
> >>
> > Agree. Why invent wheel!
> >
> >
> > --
> > Best regards. Pavel Konnikov
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Web-app-design-pattern-questions-tf3946577.html#a11201721
> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
>
>
Re: Web app design pattern questions
Posted by bilobag <bi...@hotmail.com>.
Thanks for the quick responses. I am interested in trying the mapping tool.
I am currently using Spring and noticed that you are working on some spring
integration components. Are these in a stable state? I would like to be
able to configure the jcr mapping file in my spring configuration to load at
startup. Please let me know if there is anything that currently does this.
Thanks.
Pavel Konnikov wrote:
>
> On Tue, 19 Jun 2007 18:52:00 +0400, Christophe Lombart
> <ch...@gmail.com> wrote:
>
>>> Also, is there any documentation for getting started with this?
>>
>> I would like to work on the doc asap but they are some interresting info
>> in
>> the doc folder. You can generate it with maven. Anyway, I have to
>> review it
>> due to a lot of changes since the move into Jackrabbit.
>>
> In documentation generated by maven missing pictures and on page "The
> Persistence Manager Setup" very old information.
>
> setup now more simple:
>
> ...
>
>
> session.getWorkspace().getNamespaceRegistry().registerNamespace("ocm",
> "http://jackrabbit.apache.org/ocm");
>
> String[] files = {"mapping1.xml", "mapping2.xml"};
> ObjectContentManager objectContentManager = new
> ObjectContentManagerImpl(session, files);
>
> // register namespace "ocm" and nodetypes from
> src/test/test-config/nodetypes/custom_nodetypes.xml
>
> MyObject object = new MyObject();
> object.set...();
> object.setPath("/some/path");
>
> objectContentManager.insert(object);
>
> object = (MyObject) objectContentManager.getObject("/some/path");
> objectContentManager.update();
>
> Filter filter =
> objectContentManager.getQueryManager().createFilter(MyObject.class);
> Query query =
> objectContentManager.getQueryManager().createQuery(filter);
> objectContentManager.remove(object);
>
> objectContentManager.save();
>
> ...
>
> It is very simple!
>
>>> So the wrapper class design isn't a good idea?
>>
>> not for me :-) maybe others can have another point of view
>>
> Agree. Why invent wheel!
>
>
> --
> Best regards. Pavel Konnikov
>
>
--
View this message in context: http://www.nabble.com/Web-app-design-pattern-questions-tf3946577.html#a11201721
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Web app design pattern questions
Posted by Pavel Konnikov <ko...@gmail.com>.
On Tue, 19 Jun 2007 18:52:00 +0400, Christophe Lombart
<ch...@gmail.com> wrote:
>> Also, is there any documentation for getting started with this?
>
> I would like to work on the doc asap but they are some interresting info
> in
> the doc folder. You can generate it with maven. Anyway, I have to
> review it
> due to a lot of changes since the move into Jackrabbit.
>
In documentation generated by maven missing pictures and on page "The
Persistence Manager Setup" very old information.
setup now more simple:
...
session.getWorkspace().getNamespaceRegistry().registerNamespace("ocm",
"http://jackrabbit.apache.org/ocm");
String[] files = {"mapping1.xml", "mapping2.xml"};
ObjectContentManager objectContentManager = new
ObjectContentManagerImpl(session, files);
// register namespace "ocm" and nodetypes from
src/test/test-config/nodetypes/custom_nodetypes.xml
MyObject object = new MyObject();
object.set...();
object.setPath("/some/path");
objectContentManager.insert(object);
object = (MyObject) objectContentManager.getObject("/some/path");
objectContentManager.update();
Filter filter =
objectContentManager.getQueryManager().createFilter(MyObject.class);
Query query =
objectContentManager.getQueryManager().createQuery(filter);
objectContentManager.remove(object);
objectContentManager.save();
...
It is very simple!
>> So the wrapper class design isn't a good idea?
>
> not for me :-) maybe others can have another point of view
>
Agree. Why invent wheel!
--
Best regards. Pavel Konnikov
Re: Web app design pattern questions
Posted by Christophe Lombart <ch...@gmail.com>.
On 6/19/07, bilobag <bi...@hotmail.com> wrote:
>
>
> I read about the mapping tool, but i didn't think it was in a stable
> condition.
Well, it is not so bad. They are more and more unit tests.
I think we are almost ready to create its first release (see my previous
post on that topic).
Also, is there any documentation for getting started with this?
I would like to work on the doc asap but they are some interresting info in
the doc folder. You can generate it with maven. Anyway, I have to review it
due to a lot of changes since the move into Jackrabbit.
So the wrapper class design isn't a good idea?
not for me :-) maybe others can have another point of view
Re: Web app design pattern questions
Posted by bilobag <bi...@hotmail.com>.
I read about the mapping tool, but i didn't think it was in a stable
condition. Also, is there any documentation for getting started with this?
So the wrapper class design isn't a good idea?
Christophe Lombart wrote:
>
> Hi
>
> DTO is a nice design pattern.
> Why not to use the Jackarabbit ocm tools (see in
> contrib/jackrabbit-jcr-mapping/jcr-mapping.
> By this way, you can have your wrapper classes/DTOs matching to JCR nodes.
>
> br
> Christophe
>
> On 6/19/07, bilobag <bi...@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:
>>
>> 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.
>>
>> 2) When adding a node, if I use my node wrapper classes, I will call
>> addNode() on the parent and wrap the child node. Then forward to the
>> form
>> page where the node data is entered...then call save(). The only issue
>> is
>> that when you call addNode, you need to specify the path/name of the
>> node.
>> I will not have this information until after the user submits the form.
>> First, how important is the path/name of the node? To me it seems like
>> it
>> should always be unique amongst nodes with the same parent. Second, this
>> goes back to my first question where i'm not sure whether to use DTO's or
>> node wrapper classes. If i use DTO's, adding won't be an issue. Please
>> give any design advice you may have. Thanks.
>> --
>> View this message in context:
>> http://www.nabble.com/Web-app-design-pattern-questions-tf3946577.html#a11195283
>> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Web-app-design-pattern-questions-tf3946577.html#a11196024
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Web app design pattern questions
Posted by Christophe Lombart <ch...@gmail.com>.
Hi
DTO is a nice design pattern.
Why not to use the Jackarabbit ocm tools (see in
contrib/jackrabbit-jcr-mapping/jcr-mapping.
By this way, you can have your wrapper classes/DTOs matching to JCR nodes.
br
Christophe
On 6/19/07, bilobag <bi...@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:
>
> 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.
>
> 2) When adding a node, if I use my node wrapper classes, I will call
> addNode() on the parent and wrap the child node. Then forward to the form
> page where the node data is entered...then call save(). The only issue is
> that when you call addNode, you need to specify the path/name of the node.
> I will not have this information until after the user submits the form.
> First, how important is the path/name of the node? To me it seems like it
> should always be unique amongst nodes with the same parent. Second, this
> goes back to my first question where i'm not sure whether to use DTO's or
> node wrapper classes. If i use DTO's, adding won't be an issue. Please
> give any design advice you may have. Thanks.
> --
> View this message in context:
> http://www.nabble.com/Web-app-design-pattern-questions-tf3946577.html#a11195283
> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
>
>