I've been watching this conversation from the sidelines. I see in the email
description below the purpose of the new "Dialog" object:
1.
>>�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
<action
path="/action/rates/GetAutoRateQuote"
type="com.xxx.xxx.StartAutoRateQuote"
name="formName"
dialogName="dialogName" /* THIS WOULD BE HOW MULTIPLE ACTIONS CAN
BE GROUPED AS A DIALOG" */
validate="false">
<forward name="success" path="/jsp/path/thejsp.jsp"/>
</action>
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.
Regards...djsuarez
-----Original Message-----
From: Ted Husted [mailto:[EMAIL PROTECTED]
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 :)
-Ted.
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
>>�<[EMAIL PROTECTED]>�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: [EMAIL PROTECTED]
>>>�For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>
>>�------------------------------------------------------------------
>>�--- To unsubscribe, e-mail: [EMAIL PROTECTED] For
>>�additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
