struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gvanma...@comcast.net (Gary VanMatre)
Subject Re: [shale] Why does <subdialog> data disappear when terminating?
Date Thu, 01 Sep 2005 21:15:58 GMT
>On 9/1/05, Craig McClanahan <craigmcc@gmail.com> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message