Thanks for your feedback Mike, that makes sense!
How about using another DataObject that hasn't been registered with the
context to collect the data and then copy that data over to a live
DataObject. All in one fetch, update, commit cycle like you suggested.
For new objects I guess I don't need a separate object. When it's filled
out I'll only need to register it with the context and submit it.
Fredrik Liden
ENLASO Corporation
T: 415-512-8800
E: flide..ranslate.com <mailto:fliden@translate.com>
ENLASO Corporation (formerly RWS Group, LLC) provides quality enterprise
language solutions and exceeds client expectations through continuing
research, development, and implementatio of effective localization
processes and technologies.
Visit: <http://www.translate.com/> for more information or to subscribe
to our complimentary localization newsletter.
-----Original Message-----
From: Mike Kienenberger [mailto:mkienen..laska.net]
Sent: Wednesday, February 16, 2005 7:06 AM
To: cayenne-use..bjectstyle.org
Cc: cayenne-use..bjectstyle.org
Subject: Re: The life of a DataObject
Fredrik Liden <flide..ranslate.com> wrote:
> When creating a Web application.
>
> Can I fetch a dataObject to view it on a view page.
> Then modify the contents of this dataObject (without comminging) over
> serveral requests cycles and then finally commit the changes.
>
> In other words, can I store the dataObject in the session so I don't
> have to fetch again for every trip to the server during some updates,
> or do I have to fetch it every time a request is processed? How long
> can a dataObject stay active before I can no longer commit it? Do I
> need some buffer object like a VO object or JavaBean?
>
> Are there any guidelines for a good design?
I don't think there's any technical reasons why you couldn't do this.
However, I consider it a bad design to leave DataObjects in a modified,
new,
or deleted state between requests.
There's never a guarantee that the user will submit the next page, nor
is
there any guarantee that the user won't hit the back button a couple of
times and start working from that point, leaving your DataContext
objects in
a strange state.
Let's assume you're using one DataContext per session. You start
creating
a new Artist object due to a user request, but don't finish collecting
all
of the information and thus don't save it. The user suddenly
back-navigates (or side-navigates) away from your Create Artist page to
a
Delete Painting page. He deletes a painting and triggers commit. At
this point, the incomplete Artist object is still in your context and
gets
committed as-is (or it causes a validation error and makes the deletion
fail).
I generally collect information required to make a change separately,
then
move it all into the DataObject and commit it in one request/response
cycle.
On the other hand, I have very few instances where data is collected in
a
multistep process.
This archive was generated by hypermail 2.0.0 : Wed Feb 16 2005 - 13:26:19 EST