The real use case is being able to have a write operation span
multiple requests (be it wizards or some other Ajax thingy), without
having to commit incrementally, but still without leaving the
DataContext in a dirty state.
I rollback the DataContext every request to ensure a dirty DataContext
doesn't spill out into other things. That basically precludes
multi-request writes. As a workaround until nested contexts were
available (in Struts), I did something like this for multi-request
operations:
1. When the action is invoked, declare a "transactionID" and map it to
a new DataContext
2. Bind the new DataContext to the thread, instead of the
HttpSession-bound one (but do not eliminate the session context)
3. In each request, include the transactionID as a hidden form field
4. After commit, call a cleanup method to ensure that created/modified
objects are brought back into the parent DataContext, and then discard
the transaction-based one
It's a little ugly, but no code really needs to change to take
advantage of it. Really, you just implement an interface in the Struts
Action, ensure you include transactionID in the form, and call a
cleanup method when you decide you're done. A ServletFilter takes care
of the rest...
I use this extensively for managing data tables, where the table is
only written after all operations (including creating new records,
editing existing, and deleting) have been completed.
Nested DataContexts eliminate the need for a lot of this (though not
all of it), and improve gaps in my ability to notify the parent
DataContext of the changes.
Incidentally, once nested DataContexts are completed, I planned on
writing a conversation-scope interceptor for WebWork, similar to the
WebFlow conversation state in Spring.
Cris
On 1/11/06, Mike Kienenberger <mkienen..mail.com> wrote:
> Possibly also a series of tabbed panes or a wizard. Tabbed panes and
> wizard-like dialogs are becoming popular in JSF. There's also the
> popup windows that you were talking about below as well.
>
> On 1/11/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
> > Answering my own question ... Assuming the view layer handles all the
> > validation on each POST before updating the model, there is one
> > general scenario where nesting is useful: when you need an ability to
> > cancel two or more screens of local changes without reverting all of
> > the local changes. It is more common in rich GUI (dialogs that pop
> > their own dialogs) than web, but I've seen it quite a few times in
> > internal business web applications.
> >
> > Still have a feeling that I am missing something, but at least I've
> > identified one realistic scenario...
> >
> > Andrus
> >
> >
> > On Jan 11, 2006, at 3:11 PM, Andrus Adamchik wrote:
> >
> > > I am working on the nested DC feature. I started by creating a demo
> > > application with Click front-end. What I discovered though is that
> > > since Click provides another layer of objects (UI stateful widgets)
> > > in front of Cayenne-based model, I can't come up with a scenario
> > > where a nested context is needed (as opposed to say a peer context)!
> > >
> > > The need for it was clear in WebObjects when object state was
> > > dynamically bound to the page, so you'd have to prepare your object
> > > model on GET without any guarantee that the matching POST would
> > > happen.
> > >
> > > But if you use frameworks like Click (and actually Struts, with
> > > ActionBean playing the "front row buffer" role), where does it fit
> > > here?
> > >
> > > I am probably just having a bad day, as I am sure there were a few
> > > important scenarios that I am missing now.
> > >
> > > Andrus
> > >
> > >
> >
> >
>
This archive was generated by hypermail 2.0.0 : Thu Jan 12 2006 - 14:32:39 EST