>On 9/1/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > >> >> It's like the difference between reusing common code by refactoring it >> into a separate method, and calling it, versus reusing common code by >> cut-n-paste. I prefer the former :-). Incidentally, this aspect of dialog's >> design came straight from Spring WebFlow, which draws the same sort of >> distinction (although they manage per-webflow state quite a lot >> differently). >> > >Of course, right after I pressed Send I thought of an even clearer way to >look at it ... the state object of a subdialog is like the local variables >stack of a method call that is currently in progress. It's contents are >visible *within* that subdialog/method, but not outside.
Just kind of thinking out loud here, Forte TOOL had what I thought was a pretty advanced transactional capability that allows you to define a transactional unit of work on an object that was not associated with the database. You could populate a plain object; start a transaction and then rollback the state. The unit of work was also coordinated among distributed objects but I thought the non distributed object state management was unique. I'm not sure if this would fit into the context of the dialog transactional state, but I wonder if the managed bean name could be used to simulate a transactional context. What about generating a transaction id/token that is appended to the managed bean name, a component similar to the Token component and a variable resolver? Gary --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
