ok, so the memento's are not incremental? Then only one memento should be
enough to restore the order back to the state the user created. That sound
good. I'll try that.
thanx
2008/2/11, Scott Swank [EMAIL PROTECTED]:
The order has methods createMemento():Memento and applyMemento(Memento
m).
because I use the domain objects directly,. without any DTO's, I have to use
the long conversation pattern. That means I have to store the domain object
somewhere in the session and let the loadabledetachable model retrieve it
from there?
2008/2/11, Igor Vaynberg [EMAIL PROTECTED]:
then you
On Mon, 11 Feb 2008, Martijn Lindhout wrote:
because I use the domain objects directly,. without any DTO's, I have to use
the long conversation pattern. That means I have to store the domain object
somewhere in the session and let the loadabledetachable model retrieve it
from there?
Depends
The order has methods createMemento():Memento and applyMemento(Memento
m). These are used to get objects that contain state. They can in
turn be applied to the order to set it back to that state at a later
point. So yes, you fetch the Order, detach it, call applyMemento() if
you have unsaved
that sadness is an artifact of how hibernate works. it is
easier/cheaper to create a bean than keep a disconnected session in
your http session, which can be quiet memory intensive. of course
which way you go is up to you.
in a lot of these cases i have noticed that the mapping isnt always
1:1
I suggest using the GoF memento pattern here. You keep your changes
in one or more mementos, which can be kept in the session. Then you
push the changes back to the domain model when you are happy with
them. We use this approach for modifying hotel reservations --
particularly because we need
I agree that it is *easier*, but I got bored by duplicating my domain model
in a DTO like structure. And that's cumbersome.
I saw this hapening in several projects, and in the end we had two almost
equals object structures, one with rich behavior, and one with just data and
structure.
that's
ok. never used memento, so I picked the book and read about it. I'm not sure
how to implement this. When do I retrieve a memento from the order? And in
the meantime, while adding and removing lines, is the Order updated and
saved in the DB? If someone reads the database, will he see the
The order has one or more order mementos (pre/post editing) and each
order memento has a collection of orderline mementos. The mementos
are completely opaque, and only the Order OrderLine are able to
inspect them and extract their content -- perhaps by implementing them
a static inner classes
sounds interesting. Can you explain a bit more? How does this work for
example in an Order-OrderLine situation where you edit an existing order by
adding and removing orderlines and finally do a commit or rollback?
2008/2/11, Scott Swank [EMAIL PROTECTED]:
I suggest using the GoF memento
then you have to use a bean, and on confirm apply changes from the
bean to the persistent entity. the only other alternative i know of is
to use the long conversation pattern which i am not really a fan of.
-igor
On Feb 10, 2008 11:25 PM, Martijn Lindhout [EMAIL PROTECTED] wrote:
ok, that
ok, that makes sense.
But what if I have a Hibernate persisted entity that I want to edit in
multiple actions? Say I have an order with orderlines, and I want to add and
remove them at will, and in the end save or rollback all the changes? I
don't want the intermediate add and removes propagate
Hi,
I have a page, with those two constructors, the first for editing a new
employee, the second for editing an existing.
public EditEmployee() {
setModel(new CompoundPropertyModel(new LoadableDetachableModel(){
protected Object load() {
return new
the other constructor i presume is getting a persistent entity? so
hibernate/jpa will flush state back to db at the end of request, thats
why that works.
-igor
On Feb 9, 2008 11:08 AM, Martijn Lindhout [EMAIL PROTECTED] wrote:
ok, thanx, that seems to work.
And what about the other
ok, thanx, that seems to work.
And what about the other constructor, when editing an existing entity?
2008/2/9, Igor Vaynberg [EMAIL PROTECTED]:
setModel(new CompoundPropertyModel(new LoadableDetachableModel(){
^ that is bad because ldm is cleared between requests, thats why its
called
setModel(new CompoundPropertyModel(new LoadableDetachableModel(){
^ that is bad because ldm is cleared between requests, thats why its
called loadable
just do this
setModel(new CPM(new Employee()));
-igor
On Feb 9, 2008 10:45 AM, Martijn Lindhout [EMAIL PROTECTED] wrote:
Hi,
I have a
16 matches
Mail list logo
