Fredrik Liden <flide..ranslate.com> wrote:
> 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.
Yes, I'd think that'd work great. The only situation you'll need to watch
out for is setting relationships to other DataObjects. That requires a
backing DataContext.
For working with existing objects, you can cheat and create a new
temporaryDataContext, use temporaryDataContext.localObjects() to pull a copy
into your DataContext, then unregister it from the temporaryDataContext to
get a transient copy.
Another possiblity might be to create a non-shared DataContext and just do
all of your work in that rather than in the session DataContext.
Things like invalidateObjects() as well as commitChanges() propagate those
changes around to other DataContexts normally, but you can specify
non-shared behavior with DataContext.createDataContext(false). You'd just
need to be sure that you're working with the right DataContext.
http://www.objectstyle.org/cayenne/userguide/design/caching.html
-Mike
> -----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:50:53 EST