Well keep in mind that -- especially if you have a good persistent
object squeezer -- it's only the user-mutable values that you have to
repeat. And what's more, it's only the *currently editable* values.
So it's not like Struts where you have to unload your whole bloody
domain into the page and back again all the time. And it's also not
like Struts where you're always manually stuffing model objects in
and out of IDs to get at the view. You just need to keep currently
"values in flux" out of the model while they're in flux. It's really
not so bad in practice.
Cheers,
Paul
On May 2, 2006, at 10:43 PM, Jim Steinberger wrote:
Paul, thanks a lot for your insight; I'm finding it very very helpful.
The only thing I'm really not excited about with this approach is
the
number of times my domain-properties are going to be repeated
throughout
my page classes and/or value-objects.
After struggling to maintain Struts ActionForms in the face of
domain-changes, seeing how HTML forms can be tied directly to
domain-objects via OGNL in Tapestry was a big selling point behind
getting me to switch.
I'm just pouting, though -- I appreciate the necessity of a data-
buffer
at the UI level, particularly when dealing with a persistence
mechanism
that can potentially leave objects in an indeterminate state.
Thanks again,
Jim
-----Original Message-----
From: Paul Cantrell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 02, 2006 10:09 PM
To: Tapestry users
Subject: Re: Insert/Update pages and Hibernate
Jim --
My suggestion would be to keep all the user-entered values around in
an object that's not the manufacturer, but is solely a value object
that is very specific to this particular UI. In most cases, this is
the page class itself:
class CreateEditManufacturer extends BasePage {
public abstract get/setName();
public abstract get/setFlavor();
public abstract get/setBossesFavoriteMarxBrother();
...etc...
public IPage saveManufacturer() {
try {
getManufacturer().setName(getName());
getManufacturer().setBossesFavoriteMarxBrother
(getBossesFavoriteMarxBrother());
...etc...
getManufacturerService().createManufacturer();
} catch (Exception e) {
setError("Could not create Manufacturer: " + e.getMessage());
return this;
}
}
}
But perhaps you have a multi-page process or something, where it
becomes simpler to build up the user's responses in a _value object_:
class CreateEditManufacturer extends BasePage {
@Persist("server")
public abstract ManufacturerEntryForm get/
setManufacturerEntryForm();
public IPage saveManufacturer() {
try {
values = getManufacturerValues();
getManufacturer().setName(values.getName());
getManufacturer().setBossesFavoriteMarxBrother
(values.getBossesFavoriteMarxBrother());
...etc...
getManufacturerService().createManufacturer();
} catch (Exception e) {
setError("Could not create Manufacturer: " + e.getMessage());
return this;
}
}
}
class ManufacturerEntryForm implements Serializable { // *not*
persistable!
...
}
Either way, the point is that you keep the user's input in a value
object of some kind, page or otherwise, that is -- this is the key --
modeled after the user interface, *not* after the domain object. The
value object is a transcription of what the user entered.
Only when you're ready to do something committable do you apply
changes from the UI to the domain. So you're not cloning the domain
object; you're just not eagerly applying changes to the domain at
each step.
This is not an "always the right answer" practice; it's just a
"usually works best" practice.
But yes, in any case, you're quite right: Hibernate doesn't do any
kind of in-memory rollback on your objects! No matter what approach
you take, you *cannot* manipulate a domain object unless you're
prepared to either (1) commit it or (2) discard it.
Cheers,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
