struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Suarez" <>
Subject RE: [shale] Re: Struts Shale
Date Fri, 21 Jan 2005 14:05:31 GMT
I've been watching this conversation from the sidelines.  I see in the email description below
the purpose of the new "Dialog" object:

>> To me, the lifetime of the state information is the key
>> distinguishing feature to this gadget -- so if we don't like
>> "dialog" then maybe some name around that idea would be more
>> appropriate.

Are there any other things that make this object unique?  Are there current examples of how
it would be set up or used?  I was thinking about how this idea would be implemented if #1
was the only requirement and came up with the following.  I hope it adds value to the discussion.

I took a look at the DialogController Shale source and it seems that the methods are defined
via "code" but the goal is essentially to replicate session at a smaller level.  If this is
the only case (and I may be way off base here) why not introduce a mock "session" object so
that the actions/etc are none the wiser.  The end of a dialog would be defined by some "final"
action that would clean up the session so the Cancel/Complete wouldn't matter.  Here's some
pseudo-code to show what I was thinking:

	// I have no clue on Shale config so this is basically a struts example that would need to
be modified for the equivalents in Shale
	    <forward name="success" path="/jsp/path/thejsp.jsp"/>

At the server you check if a dialogName exists, if so then it's a dialog.  If that dialog
is not currently in existence, then create a session space for it:

   	if(session.getActiveDialogs().get(dialogName)==null){ //no session with that name exists
   		webSession = session; // Just to illustrate that this is the "REAL" session
   		dialogSession = new dialogSession(session); // session is passed so the user can use
the same session life-cycle methods on a mini scale and it has a reference to the "real" session
object as needed to look up objects.  If it is not found in dialog session it can then check
"real" session
   		webSession.set(DIALOGSESSION+"_"+dialogName, dialogSession);   //Give the dialog session
a spot in the real session		
	//The call to the action/dialog in this case would pass the dialogSession instead of the
real session in this case.  So a call to session.invalidate() would just remove the dialog
from the real session.  

Maybe there are other goals for dialog that I am not aware of that this would not work for.
 I think the above would essentially make a struts app a series of dialogs for the most part
except probably the login/logout and other universal functions.  Of course the naming above
would be confusing as hell so you'd probably want to use better names in the "execute" type
method so the user doesn't think they're working with a session.  Maybe a name like "Scope",
so you're passed a scope as part of the execute method to make it clear that any of the work
you do is limited to whatever the configuration scope is (handled as part of config).

Please advise how this may or may not suit your needs.  I hope I'm not 100% off-base here.


-----Original Message-----
From: Ted Husted [] 
Sent: Thursday, January 20, 2005 5:04 AM
To: Struts Developers List
Subject: Re: [shale] Re: Struts Shale

It would be a good idea to name both the set and the member at the same time. 

Some suggestions

* Activity and Task
* Circuit and Gate
* Track and Step 
* Process and Node

which leads to conjugations like 

* ActivityState
* CircuitState
* TrackState
* ProcessState

If this were Friday, I might add 

* Ripple and Domino :)


On Thu, 20 Jan 2005 05:07:03 +0000, Duncan Mills wrote:
> In the past I've been around this merry-go-round on another
> Controller implementation, the end result of that painful exercise
> in semantics was the following:
> 1) An activity - a single node on the flow - display a page, send
> an email, execute this code etc.
> 2) A Process - a group of activities,  logically of course this
> process itself can be nested as an activity in a flow.
> So this is why I tend to use process, it's also neutral enough to
> (I think) co-exist with the scope's we're used to.  Another factor
> here is that using an overloaded term (like dialog) is acceptable
> to a native English speaker but can be confusing if English is not
> your primary language, this would also rule out a term like Wizard.
> Duncan
> Craig McClanahan wrote:
>> The only problem I have with "wizard" is that it implies a serial
>> forwards-backwards flow.  I can see cases for dialogs :-) with
>> branches in them.  (It's the same reason I took standard "next"
>> and "previous" methods back out of the API ... the concept
>> doesn't always apply.
>> To me, the lifetime of the state information is the key
>> distinguishing feature to this gadget -- so if we don't like
>> "dialog" then maybe some name around that idea would be more
>> appropriate.
>> Craig
>> On Tue, 18 Jan 2005 15:16:16 -0500, Sean Schofield
>> <> wrote:
>>>> I almost suggested the same thing: "conversation".  Its
>>>> length, though, could be unfriendly.  ConversationController.
>>>> What about "dialogue" with the "ue" at the end?
>>> What about "wizard?"  This is what we call our own custom
>>> solution that we're using now.  Wizard generally implies a
>>> guided series of steps where you can go forwards and backwards
>>> (at least to me it does.)
>>> sean
>>> ----------------------------------------------------------------
>>> ----- To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ------------------------------------------------------------------
>> --- To unsubscribe, e-mail: For
>> additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message