You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Stefan Langer <my...@bettsockentraeger.de> on 2005/01/18 09:25:16 UTC
[shale] Re: Struts Shale
Hello Craig,
I see your point and I think you are right but there is one disadvantage
leaving the coding of the prev and next button up to the developer. Most
of the times the developers do not clean up the session when using a
dialogflow or a pageflow. This leaves a lot of garbage in the session
bloating it up. So if the framwork could provide a mechanism for making
this easier I think the whole application will benefit from it. This
framework could be seperate from the actual dialogcontroller so only
those people can use it that need it or want to benefit from it.
My thinking is this is infrastructure so it should be covered by the
framework and not on a per application level.
Another side effect of this could be the possibility to provide a mean
to navigate backwards using the standard browser back button.
Craig McClanahan wrote:
> On Fri, 14 Jan 2005 09:27:51 +0100, Stefan Langer
> <my...@bettsockentraeger.de> wrote:
>
>>Hello,
>>
>>not sure if I'm addressing the right person, got your mail off the
>>myfaces mailing list. If addressing is wrong ignore this mail.
>>
>
>
> I'm the right person.
>
>
>>To the point I read your proposal about struts shale and jsf and find
>>your implementation very interesting and am looking forward to a
>>hopefully soon release.
>>
>>I have a few suggestions which and am wondering where I can introduce
>>them to shale. I don't want to edit the wiki directly and I didn't find
>>a comment section is there a discussion list?
>
>
> Since Shale is part of the Struts project, the best discussion list is
> the Struts developer list (to subscribe, send an empty message to
> dev-subscribe@struts.apache.org). Then, to help people sort
> conversations, it would be common to put "[shale]" in the message
> subject, so that people who are not interested could easily filter it
> out.
>
>
>>Anyhow here it goes:
>>
>>I especially like the idea of a dialogscope. The thing which I would
>>find interesting is to define the flow of a dialog in some config file
>>(preferrably xml) and being able to provide a back functionality in
>>addition to the enter, exit and cancel in the dialogcontroller.
>
>
> Interesting ... I had next() and previous() methods in my original
> design for this API.
>
>
>>This
>>would make creating wizard like dialogs very easy and provide a way to
>>navigate through the dialog in both directions.
>
>
> The reasons I don't have next() and previous() at the moment are as follows:
>
> * Wizards tend to have a sequential flow (forwards and backwards)
> but that isn't the only kind of dialog that needs to be supported.
> The methods would go unused in some cases.
>
> * Manually implementing next and previous functionality (as I did in
> the "use cases" example app) is so easy to do that it's hard to
> see much benefit from having the methods directly implemented.
>
> * A generic "next" or "previous" method would have to be aware of
> all the possible logical outcomes, and this list would have to be
> updated every time a new step was added. In the current approach
> an event handler only has to know the outcome ot get to the
> adjacent view, and isn't affected when new steps are added (unless
> it is adjacent).
>
> Does that make sense?
>
>
>>Taking the
>>synchronization token pattern in account it might even be possible to
>>provide the same data when the user presses the browser back button.
>
>
> I think this is going to require some assistance from the state saving
> machinery that JSF provides, but it would be interesting. It might
> also be that the user still expects the state information to be the
> most current state, just like they would get from a regular "previous"
> button.
>
>
>>The advantage of a flow control is that the session can be cleaned
>>fairly easy when skipping from one dialog to the other and information
>>is not unnessecarly stored.
>
>
> My current thinking is that we want the ability to have more than one
> active dialog, so you can "push" from one dialog to another, then
> "pop" back out. That's why I made it the dialog's responsibility to
> clean itself up.
>
> I don't like the fact that the dialog has to know the attribute name
> it is stored under (in session scope), but haven't figured out a way
> around it yet.
>
>
>>Regards
>>
>>Stefan Langer
>>
>>
>
>
> Craig
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Dakota Jack <da...@gmail.com>.
<snip>
> > Craig Wrote:
> > > > My current thinking is that we want the ability to have more than one
> > > > active dialog, so you can "push" from one dialog to another, then
> > > > "pop" back out. That's why I made it the dialog's responsibility to
> > > > clean itself up.
> > > >
> > > > I don't like the fact that the dialog has to know the attribute name
> > > > it is stored under (in session scope), but haven't figured out a way
> > > > around it yet.
> > > >
> > > >
> > > > Craig
</snip>
In my experience, this sort of program, app, or whatever you want to
call it, is better stored in application scope. That way there are no
limits to the algorithms you can foster.
Jack
--
------------------------------
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
-----------------------------------------------
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Craig McClanahan <cr...@gmail.com>.
On Thu, 20 Jan 2005 11:54:06 -0600, Michael Rasmussen
<ra...@gmail.com> wrote:
> Craig Wrote:
> > > My current thinking is that we want the ability to have more than one
> > > active dialog, so you can "push" from one dialog to another, then
> > > "pop" back out. That's why I made it the dialog's responsibility to
> > > clean itself up.
> > >
> > > I don't like the fact that the dialog has to know the attribute name
> > > it is stored under (in session scope), but haven't figured out a way
> > > around it yet.
> > >
> > >
> > > Craig
> > >
> >
>
> I'm curious, could a dialog, or whatever it ends up being called, have
> the ability to create "sub dialogs"? These sub-dialogs could be put
> into a sandbox that the parent deletes upon exit.
Or even a stack, for that matter, so you can have arbitrary nesting.
(Although that wouldn't deal with the multiple-window case where you
might have a separate dialog going in each.)
> Keeping the sub
> dialogs in a collection of some sort would allow for multiple paralell
> dialogs. Having a master dialor for the session that is always there
> would allow for even the "top-level" dialogs to be removed and none of
> them would have to know their own names anymore. Right?
As it's currently implemented, the dialog comes into existence (and
gets stored in session scope) as a side effect of being loaded as a
managed bean. Therefore, right now, there's no notification to the
framework to put that very first dialog into any sort of collection.
That probably
needs to change in order to deal with this particular issue.
Duncan had a suggestion related to that, of using the plugin
capability on the NavigationHandler to recognize when you are
navigating to a dialog for the first time. That bears some
investigation as well.
>
> Michael
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Michael Rasmussen <ra...@gmail.com>.
Craig Wrote:
> > My current thinking is that we want the ability to have more than one
> > active dialog, so you can "push" from one dialog to another, then
> > "pop" back out. That's why I made it the dialog's responsibility to
> > clean itself up.
> >
> > I don't like the fact that the dialog has to know the attribute name
> > it is stored under (in session scope), but haven't figured out a way
> > around it yet.
> >
> >
> > Craig
> >
>
I'm curious, could a dialog, or whatever it ends up being called, have
the ability to create "sub dialogs"? These sub-dialogs could be put
into a sandbox that the parent deletes upon exit. Keeping the sub
dialogs in a collection of some sort would allow for multiple paralell
dialogs. Having a master dialor for the session that is always there
would allow for even the "top-level" dialogs to be removed and none of
them would have to know their own names anymore. Right?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Ted Husted <hu...@apache.org>.
No one is suggesting that Shale is off-topic. Using these types of remarks in a subject line is an established courtesy on higher-traffic lists.
The Shale codebase lives here, and Struts Dev is the preferred list for posts regarding Struts Shale.
'nuff said.
-Ted.
On Tue, 18 Jan 2005 06:48:37 -0800, Dakota Jack wrote:
>�I have to smile at the suggestion that "[shale]" will be a
>�substitute for "OT" so that Struts developers will not be burdened
>�by these JSF discussions. �That is exactly the sentiment of Rod
>�Johnson in "J2EE Development without EJB". �I also agree. �What
>�could be more ironic than a proposed future of a project being
>�clearly OT? �LOL �Talk about 1984!
>
>�Jack
>
>
>�On Tue, 18 Jan 2005 09:25:16 +0100, Stefan Langer
>�<my...@bettsockentraeger.de>�wrote:
>>�Hello Craig,
>>
>>�I see your point and I think you are right but there is one
>>�disadvantage leaving the coding of the prev and next button up to
>>�the developer. Most of the times the developers do not clean up
>>�the session when using a dialogflow or a pageflow. This leaves a
>>�lot of garbage in the session bloating it up. So if the framwork
>>�could provide a mechanism for making this easier I think the
>>�whole application will benefit from it. This framework could be
>>�seperate from the actual dialogcontroller so only those people
>>�can use it that need it or want to benefit from it. My thinking
>>�is this is infrastructure so it should be covered by the
>>�framework and not on a per application level.
>>�Another side effect of this could be the possibility to provide a
>>�mean to navigate backwards using the standard browser back button.
>>
>>�Craig McClanahan wrote:
>>>�On Fri, 14 Jan 2005 09:27:51 +0100, Stefan Langer
>>>�<my...@bettsockentraeger.de>�wrote:
>>>
>>>>�Hello,
>>>>
>>>>�not sure if I'm addressing the right person, got your mail
>>>>�off the myfaces mailing list. If addressing is wrong ignore
>>>>�this mail.
>>>>
>>>
>>>�I'm the right person.
>>>
>>>
>>>>�To the point I read your proposal about struts shale and jsf
>>>>�and find your implementation very interesting and am looking
>>>>�forward to a hopefully soon release.
>>>>
>>>>�I have a few suggestions which and am wondering where I can
>>>>�introduce them to shale. I don't want to edit the wiki
>>>>�directly and I didn't find a comment section is there a
>>>>�discussion list?
>>>
>>>
>>>�Since Shale is part of the Struts project, the best discussion
>>>�list is the Struts developer list (to subscribe, send an empty
>>>�message to dev-subscribe@struts.apache.org). �Then, to help
>>>�people sort conversations, it would be common to put "[shale]"
>>>�in the message subject, so that people who are not interested
>>>�could easily filter it out.
>>>
>>>
>>>>�Anyhow here it goes:
>>>>
>>>>�I especially like the idea of a dialogscope. The thing which
>>>>�I would find interesting is to define the flow of a dialog in
>>>>�some config file (preferrably xml) and being able to provide
>>>>�a back functionality in addition to the enter, exit and
>>>>�cancel in the dialogcontroller.
>>>
>>>
>>>�Interesting ... I had next() and previous() methods in my
>>>�original design for this API.
>>>
>>>
>>>>�This
>>>>�would make creating wizard like dialogs very easy and provide
>>>>�a way to navigate through the dialog in both directions.
>>>
>>>
>>>�The reasons I don't have next() and previous() at the moment
>>>�are as follows:
>>>
>>>�* Wizards tend to have a sequential flow (forwards and
>>>�backwards) but that isn't the only kind of dialog that needs to
>>>�be supported. The methods would go unused in some cases.
>>>
>>>�* Manually implementing next and previous functionality (as I
>>>�did in the "use cases" example app) is so easy to do that it's
>>>�hard to see much benefit from having the methods directly
>>>�implemented.
>>>
>>>�* A generic "next" or "previous" method would have to be aware
>>>�of all the possible logical outcomes, and this list would have
>>>�to be updated every time a new step was added. �In the current
>>>�approach an event handler only has to know the outcome ot get
>>>�to the adjacent view, and isn't affected when new steps are
>>>�added (unless it is adjacent).
>>>
>>>�Does that make sense?
>>>
>>>
>>>>�Taking the
>>>>�synchronization token pattern in account it might even be
>>>>�possible to provide the same data when the user presses the
>>>>�browser back button.
>>>
>>>
>>>�I think this is going to require some assistance from the state
>>>�saving machinery that JSF provides, but it would be
>>>�interesting. �It might also be that the user still expects the
>>>�state information to be the most current state, just like they
>>>�would get from a regular "previous" button.
>>>
>>>
>>>>�The advantage of a flow control is that the session can be
>>>>�cleaned fairly easy when skipping from one dialog to the
>>>>�other and information is not unnessecarly stored.
>>>
>>>
>>>�My current thinking is that we want the ability to have more
>>>�than one active dialog, so you can "push" from one dialog to
>>>�another, then "pop" back out. �That's why I made it the
>>>�dialog's responsibility to clean itself up.
>>>
>>>�I don't like the fact that the dialog has to know the attribute
>>>�name it is stored under (in session scope), but haven't figured
>>>�out a way around it yet.
>>>
>>>
>>>>�Regards
>>>>
>>>>�Stefan Langer
>>>>
>>>
>>>�Craig
>>>
>>
>>�------------------------------------------------------------------
>>�--- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>�For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>�--
>�------------------------------
>
>�"You can lead a horse to water but you cannot make it float on its
>�back."
>
>�~Dakota Jack~
>
>�"You can't wake a person who is pretending to be asleep."
>
>�~Native Proverb~
>
>�"Each man is good in His sight. It is not necessary for eagles to
>�be crows."
>
>�~Hunkesni (Sitting Bull), Hunkpapa Sioux~
>
>�-----------------------------------------------
>
>�"This message may contain confidential and/or privileged
>�information. If you are not the addressee or authorized to receive
>�this for the addressee, you must not use, copy, disclose, or take
>�any action based on this message or any information herein. If you
>�have received this message in error, please advise the sender
>�immediately by reply e-mail and delete this message. Thank you for
>�your cooperation."
>
>�--------------------------------------------------------------------
>�- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>�additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Dakota Jack <da...@gmail.com>.
I have to smile at the suggestion that "[shale]" will be a substitute
for "OT" so that Struts developers will not be burdened by these JSF
discussions. That is exactly the sentiment of Rod Johnson in "J2EE
Development without EJB". I also agree. What could be more ironic
than a proposed future of a project being clearly OT? LOL Talk about
1984!
Jack
On Tue, 18 Jan 2005 09:25:16 +0100, Stefan Langer
<my...@bettsockentraeger.de> wrote:
> Hello Craig,
>
> I see your point and I think you are right but there is one disadvantage
> leaving the coding of the prev and next button up to the developer. Most
> of the times the developers do not clean up the session when using a
> dialogflow or a pageflow. This leaves a lot of garbage in the session
> bloating it up. So if the framwork could provide a mechanism for making
> this easier I think the whole application will benefit from it. This
> framework could be seperate from the actual dialogcontroller so only
> those people can use it that need it or want to benefit from it.
> My thinking is this is infrastructure so it should be covered by the
> framework and not on a per application level.
> Another side effect of this could be the possibility to provide a mean
> to navigate backwards using the standard browser back button.
>
> Craig McClanahan wrote:
> > On Fri, 14 Jan 2005 09:27:51 +0100, Stefan Langer
> > <my...@bettsockentraeger.de> wrote:
> >
> >>Hello,
> >>
> >>not sure if I'm addressing the right person, got your mail off the
> >>myfaces mailing list. If addressing is wrong ignore this mail.
> >>
> >
> >
> > I'm the right person.
> >
> >
> >>To the point I read your proposal about struts shale and jsf and find
> >>your implementation very interesting and am looking forward to a
> >>hopefully soon release.
> >>
> >>I have a few suggestions which and am wondering where I can introduce
> >>them to shale. I don't want to edit the wiki directly and I didn't find
> >>a comment section is there a discussion list?
> >
> >
> > Since Shale is part of the Struts project, the best discussion list is
> > the Struts developer list (to subscribe, send an empty message to
> > dev-subscribe@struts.apache.org). Then, to help people sort
> > conversations, it would be common to put "[shale]" in the message
> > subject, so that people who are not interested could easily filter it
> > out.
> >
> >
> >>Anyhow here it goes:
> >>
> >>I especially like the idea of a dialogscope. The thing which I would
> >>find interesting is to define the flow of a dialog in some config file
> >>(preferrably xml) and being able to provide a back functionality in
> >>addition to the enter, exit and cancel in the dialogcontroller.
> >
> >
> > Interesting ... I had next() and previous() methods in my original
> > design for this API.
> >
> >
> >>This
> >>would make creating wizard like dialogs very easy and provide a way to
> >>navigate through the dialog in both directions.
> >
> >
> > The reasons I don't have next() and previous() at the moment are as follows:
> >
> > * Wizards tend to have a sequential flow (forwards and backwards)
> > but that isn't the only kind of dialog that needs to be supported.
> > The methods would go unused in some cases.
> >
> > * Manually implementing next and previous functionality (as I did in
> > the "use cases" example app) is so easy to do that it's hard to
> > see much benefit from having the methods directly implemented.
> >
> > * A generic "next" or "previous" method would have to be aware of
> > all the possible logical outcomes, and this list would have to be
> > updated every time a new step was added. In the current approach
> > an event handler only has to know the outcome ot get to the
> > adjacent view, and isn't affected when new steps are added (unless
> > it is adjacent).
> >
> > Does that make sense?
> >
> >
> >>Taking the
> >>synchronization token pattern in account it might even be possible to
> >>provide the same data when the user presses the browser back button.
> >
> >
> > I think this is going to require some assistance from the state saving
> > machinery that JSF provides, but it would be interesting. It might
> > also be that the user still expects the state information to be the
> > most current state, just like they would get from a regular "previous"
> > button.
> >
> >
> >>The advantage of a flow control is that the session can be cleaned
> >>fairly easy when skipping from one dialog to the other and information
> >>is not unnessecarly stored.
> >
> >
> > My current thinking is that we want the ability to have more than one
> > active dialog, so you can "push" from one dialog to another, then
> > "pop" back out. That's why I made it the dialog's responsibility to
> > clean itself up.
> >
> > I don't like the fact that the dialog has to know the attribute name
> > it is stored under (in session scope), but haven't figured out a way
> > around it yet.
> >
> >
> >>Regards
> >>
> >>Stefan Langer
> >>
> >>
> >
> >
> > Craig
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
------------------------------
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
-----------------------------------------------
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by BERNARDO ANTONIO BUFFA <kr...@bbs.frc.utn.edu.ar>.
What about a "UseCase", who keeps track of the state of the
(dialog|conversation|navigation) with the user?
No need to separate in Action (behavior of a object) and ActionForm (state
of a object). Just an UseCase (oder MongoMongoBanana) to invoke its
methods via reflection (a la DispatchAction).
Bernardo Antonio Buffa Colomé
kreimer@bbs.frc.utn.edu.ar
> 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
> <se...@gmail.com> 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Dakota Jack <da...@gmail.com>.
Oh, I see, Craig. I usually assume that the email I got was from the
list rather than from an individual and with a copy to the list. So,
I thought I was responding to the list. Here it goes to the list.
Jack
On Thu, 20 Jan 2005 20:42:01 -0800, Dakota Jack <da...@gmail.com> wrote:
> <snip>
> On Thu, 20 Jan 2005 18:43:09 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> > (How about replying on-list so others see the q&a? :-)
> </snip>
>
> ???
>
> <snip>
> > For shorter than a request, it doesn't seem to me that an app needs
> > much help -- just stick the thing in request scope and it'll get
> > cleaned up in some reasonable amount of time for you. Cleaning up
> > faster doesn't seem like a value add.
> </snip>
>
> Transactions? Other similar "wait and see deals" which may or may not
> be GUI related?
>
> <snip>
> > For longer than a session (including cases where you might need to go
> > get an email confirmation, for example), we'd be getting into a
> > territory where there are lots of BPM and workflow type systems, which
> > incorporate all sorts of other bells and whistles as well. (The Agila
> > project in the Apache incubator, for example, wants to play in this
> > space.) That's an interesting problem, but it's already being covered
> > by others - I want to deliberately aim at a sweet spot that is very
> > common in webapps but doesn't have very many elegant solutions already
> > available.
> </snip>
>
> Don't these cover this area per force?
>
> Jack
>
> --
> ------------------------------
>
> "You can lead a horse to water but you cannot make it float on its back."
>
> ~Dakota Jack~
>
> "You can't wake a person who is pretending to be asleep."
>
> ~Native Proverb~
>
> "Each man is good in His sight. It is not necessary for eagles to be crows."
>
> ~Hunkesni (Sitting Bull), Hunkpapa Sioux~
>
> -----------------------------------------------
>
> "This message may contain confidential and/or privileged information.
> If you are not the addressee or authorized to receive this for the
> addressee, you must not use, copy, disclose, or take any action based
> on this message or any information herein. If you have received this
> message in error, please advise the sender immediately by reply e-mail
> and delete this message. Thank you for your cooperation."
>
--
------------------------------
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
-----------------------------------------------
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 19 Jan 2005 22:12:58 -0800, Dakota Jack <da...@gmail.com> wrote:
> ClientState?
> ViewState?
> What is the lifetime? If the lifetime = x, I would suggest XState.
X ~= "longer than a request, shorter than a session"
:-)
>
> Jack
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Dakota Jack <da...@gmail.com>.
ClientState?
ViewState?
What is the lifetime? If the lifetime = x, I would suggest XState.
Jack
On Wed, 19 Jan 2005 16:37:58 -0800, Craig McClanahan <cr...@gmail.com> 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
> <se...@gmail.com> 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: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
------------------------------
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
-----------------------------------------------
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by BERNARDO ANTONIO BUFFA <kr...@bbs.frc.utn.edu.ar>.
What about a "UseCase", who keeps track of the state of the
(dialog|conversation|navigation) with the user?
No need to separate in Action (behavior of a object) and ActionForm (state
of a object). Just an UseCase (oder MongoMongoBanana) to invoke its
methods via reflection (a la DispatchAction).
Bernardo Antonio Buffa Colomé
kreimre@bbs.frc.utn.edu.ar
> 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
> <se...@gmail.com> 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Dakota Jack <da...@gmail.com>.
Not MD_20_20_State? LOL. Anyway, I like this suggestion on any day
of the week. I think naming here is very, very important, by the way.
So much difficulty is caused by bad naming.
Jack
On Thu, 20 Jan 2005 06:04:23 -0500, Ted Husted <hu...@apache.org> wrote:
> 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
> >> <se...@gmail.com> 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: dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>
> >> ------------------------------------------------------------------
> >> --- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> >> additional commands, e-mail: dev-help@struts.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
------------------------------
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
-----------------------------------------------
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Ted Husted <hu...@apache.org>.
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
>> <se...@gmail.com> 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: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>> ------------------------------------------------------------------
>> --- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>> additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Duncan Mills <du...@oracle.com>.
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
><se...@gmail.com> 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: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
Re: [shale] Re: Struts Shale
Posted by James Mitchell <jm...@apache.org>.
We call it an "activity" on my current project. Basically, all "activities"
are begun from a tabbed main menu called "The Launchpad", and when the user
clicks on any one of the available "activities", they are taken through a
few defined steps, some dynamic (forward pages based on product from the
db), and some are wizard like.
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
----- Original Message -----
From: "Craig McClanahan" <cr...@gmail.com>
To: "Struts Developers List" <de...@struts.apache.org>; "Sean Schofield"
<se...@gmail.com>
Cc: "Hubert Rabago" <hr...@gmail.com>
Sent: Wednesday, January 19, 2005 7:37 PM
Subject: Re: [shale] Re: Struts Shale
> 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
> <se...@gmail.com> 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Craig McClanahan <cr...@gmail.com>.
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
<se...@gmail.com> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Sean Schofield <se...@gmail.com>.
> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Mike Kienenberger <mk...@alaska.net>.
Dakota Jack <da...@gmail.com> wrote:
> Duncan Mills seems to characterize this as PrivateProcess. Something
> like that seems far more didactic and helpful to me than something it
> really is not, like Dialogue or Conversation. My suggestion is that
> the name reflect precisely what it is.
Perhaps DataCollectionProcess.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Dakota Jack <da...@gmail.com>.
Duncan Mills seems to characterize this as PrivateProcess. Something
like that seems far more didactic and helpful to me than something it
really is not, like Dialogue or Conversation. My suggestion is that
the name reflect precisely what it is.
Jack
On Tue, 18 Jan 2005 13:10:54 -0600, Hubert Rabago <hr...@gmail.com> wrote:
> On Tue, 18 Jan 2005 12:41:35 -0500, Sean Schofield
> <se...@gmail.com> wrote:
> > > Regarding the name "dialog" (which Duncan also raised in his original
> > > post); I'm open to alternatives, but could not think of anything that
> > > was really more evocative. I've heard some people refer to the
> > > general idea as "transaction scope", but IMHO that doesn't really
> > > match up to what you might want to do in one of these things.
> >
> > What about conversation? I think I've heard that one thrown out there before.
>
> I almost suggested the same thing: "conversation". Its length,
> though, could be unfriendly. ConversationController.
> What about "dialogue" with the "ue" at the end?
>
> >
> > > Craig
> >
> > sean
> >
>
> Hubert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
------------------------------
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
-----------------------------------------------
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Hubert Rabago <hr...@gmail.com>.
On Tue, 18 Jan 2005 12:41:35 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > Regarding the name "dialog" (which Duncan also raised in his original
> > post); I'm open to alternatives, but could not think of anything that
> > was really more evocative. I've heard some people refer to the
> > general idea as "transaction scope", but IMHO that doesn't really
> > match up to what you might want to do in one of these things.
>
> What about conversation? I think I've heard that one thrown out there before.
I almost suggested the same thing: "conversation". Its length,
though, could be unfriendly. ConversationController.
What about "dialogue" with the "ue" at the end?
>
> > Craig
>
> sean
>
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Sean Schofield <se...@gmail.com>.
> Regarding the name "dialog" (which Duncan also raised in his original
> post); I'm open to alternatives, but could not think of anything that
> was really more evocative. I've heard some people refer to the
> general idea as "transaction scope", but IMHO that doesn't really
> match up to what you might want to do in one of these things.
What about conversation? I think I've heard that one thrown out there before.
> Craig
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Craig McClanahan <cr...@gmail.com>.
On Tue, 18 Jan 2005 17:14:56 +0000, Duncan Mills
<du...@oracle.com> wrote:
> +1, In the normal case nested process scope should be automatically
> cleaned up, however, in order for that to be useful, there also has to
> be sufficient metadata defining the process to map "return state" from
> the private process (dialog) scope to the outer scope automatically,
> plus of course trigger points for code if the developer can't express
> the desired mapping solely in metadata
> Duncan
+1 as well, as long as we still want the ability to have more than one
"dialog" active for a given user (both for nesting, but also for
multiple frames/windows). Currently, a DialogController is
responsible for removing itself from session scope in one of its
"exit" methods (adding it initially is taken care of by the managed
beans processing), which creates an ugly need to know what attribute
key it was stored under.
A plugin NavigationHandler is worth looking at (along the lines that
Duncan suggested); however, this is likely to mean the need for an
externally defined configuration file -- the standard DTD doesn't
provide any extendability in this particular area.
Regarding the name "dialog" (which Duncan also raised in his original
post); I'm open to alternatives, but could not think of anything that
was really more evocative. I've heard some people refer to the
general idea as "transaction scope", but IMHO that doesn't really
match up to what you might want to do in one of these things.
Craig
>
> Stefan Langer wrote:
>
> > Hello Craig,
> >
> > I see your point and I think you are right but there is one
> > disadvantage leaving the coding of the prev and next button up to the
> > developer. Most of the times the developers do not clean up the
> > session when using a dialogflow or a pageflow. This leaves a lot of
> > garbage in the session bloating it up. So if the framwork could
> > provide a mechanism for making this easier I think the whole
> > application will benefit from it. This framework could be seperate
> > from the actual dialogcontroller so only those people can use it that
> > need it or want to benefit from it.
> > My thinking is this is infrastructure so it should be covered by the
> > framework and not on a per application level.
> > Another side effect of this could be the possibility to provide a mean
> > to navigate backwards using the standard browser back button.
> >
> > Craig McClanahan wrote:
> >
> >> On Fri, 14 Jan 2005 09:27:51 +0100, Stefan Langer
> >> <my...@bettsockentraeger.de> wrote:
> >>
> >>> Hello,
> >>>
> >>> not sure if I'm addressing the right person, got your mail off the
> >>> myfaces mailing list. If addressing is wrong ignore this mail.
> >>>
> >>
> >>
> >> I'm the right person.
> >>
> >>
> >>> To the point I read your proposal about struts shale and jsf and find
> >>> your implementation very interesting and am looking forward to a
> >>> hopefully soon release.
> >>>
> >>> I have a few suggestions which and am wondering where I can introduce
> >>> them to shale. I don't want to edit the wiki directly and I didn't find
> >>> a comment section is there a discussion list?
> >>
> >>
> >>
> >> Since Shale is part of the Struts project, the best discussion list is
> >> the Struts developer list (to subscribe, send an empty message to
> >> dev-subscribe@struts.apache.org). Then, to help people sort
> >> conversations, it would be common to put "[shale]" in the message
> >> subject, so that people who are not interested could easily filter it
> >> out.
> >>
> >>
> >>> Anyhow here it goes:
> >>>
> >>> I especially like the idea of a dialogscope. The thing which I would
> >>> find interesting is to define the flow of a dialog in some config file
> >>> (preferrably xml) and being able to provide a back functionality in
> >>> addition to the enter, exit and cancel in the dialogcontroller.
> >>
> >>
> >>
> >> Interesting ... I had next() and previous() methods in my original
> >> design for this API.
> >>
> >>
> >>> This
> >>> would make creating wizard like dialogs very easy and provide a way to
> >>> navigate through the dialog in both directions.
> >>
> >>
> >>
> >> The reasons I don't have next() and previous() at the moment are as
> >> follows:
> >>
> >> * Wizards tend to have a sequential flow (forwards and backwards)
> >> but that isn't the only kind of dialog that needs to be supported.
> >> The methods would go unused in some cases.
> >>
> >> * Manually implementing next and previous functionality (as I did in
> >> the "use cases" example app) is so easy to do that it's hard to
> >> see much benefit from having the methods directly implemented.
> >>
> >> * A generic "next" or "previous" method would have to be aware of
> >> all the possible logical outcomes, and this list would have to be
> >> updated every time a new step was added. In the current approach
> >> an event handler only has to know the outcome ot get to the
> >> adjacent view, and isn't affected when new steps are added (unless
> >> it is adjacent).
> >>
> >> Does that make sense?
> >>
> >>
> >>> Taking the
> >>> synchronization token pattern in account it might even be possible to
> >>> provide the same data when the user presses the browser back button.
> >>
> >>
> >>
> >> I think this is going to require some assistance from the state saving
> >> machinery that JSF provides, but it would be interesting. It might
> >> also be that the user still expects the state information to be the
> >> most current state, just like they would get from a regular "previous"
> >> button.
> >>
> >>
> >>> The advantage of a flow control is that the session can be cleaned
> >>> fairly easy when skipping from one dialog to the other and information
> >>> is not unnessecarly stored.
> >>
> >>
> >>
> >> My current thinking is that we want the ability to have more than one
> >> active dialog, so you can "push" from one dialog to another, then
> >> "pop" back out. That's why I made it the dialog's responsibility to
> >> clean itself up.
> >>
> >> I don't like the fact that the dialog has to know the attribute name
> >> it is stored under (in session scope), but haven't figured out a way
> >> around it yet.
> >>
> >>
> >>> Regards
> >>>
> >>> Stefan Langer
> >>>
> >>>
> >>
> >>
> >> Craig
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Re: Struts Shale
Posted by Duncan Mills <du...@oracle.com>.
+1, In the normal case nested process scope should be automatically
cleaned up, however, in order for that to be useful, there also has to
be sufficient metadata defining the process to map "return state" from
the private process (dialog) scope to the outer scope automatically,
plus of course trigger points for code if the developer can't express
the desired mapping solely in metadata
Duncan
Stefan Langer wrote:
> Hello Craig,
>
> I see your point and I think you are right but there is one
> disadvantage leaving the coding of the prev and next button up to the
> developer. Most of the times the developers do not clean up the
> session when using a dialogflow or a pageflow. This leaves a lot of
> garbage in the session bloating it up. So if the framwork could
> provide a mechanism for making this easier I think the whole
> application will benefit from it. This framework could be seperate
> from the actual dialogcontroller so only those people can use it that
> need it or want to benefit from it.
> My thinking is this is infrastructure so it should be covered by the
> framework and not on a per application level.
> Another side effect of this could be the possibility to provide a mean
> to navigate backwards using the standard browser back button.
>
> Craig McClanahan wrote:
>
>> On Fri, 14 Jan 2005 09:27:51 +0100, Stefan Langer
>> <my...@bettsockentraeger.de> wrote:
>>
>>> Hello,
>>>
>>> not sure if I'm addressing the right person, got your mail off the
>>> myfaces mailing list. If addressing is wrong ignore this mail.
>>>
>>
>>
>> I'm the right person.
>>
>>
>>> To the point I read your proposal about struts shale and jsf and find
>>> your implementation very interesting and am looking forward to a
>>> hopefully soon release.
>>>
>>> I have a few suggestions which and am wondering where I can introduce
>>> them to shale. I don't want to edit the wiki directly and I didn't find
>>> a comment section is there a discussion list?
>>
>>
>>
>> Since Shale is part of the Struts project, the best discussion list is
>> the Struts developer list (to subscribe, send an empty message to
>> dev-subscribe@struts.apache.org). Then, to help people sort
>> conversations, it would be common to put "[shale]" in the message
>> subject, so that people who are not interested could easily filter it
>> out.
>>
>>
>>> Anyhow here it goes:
>>>
>>> I especially like the idea of a dialogscope. The thing which I would
>>> find interesting is to define the flow of a dialog in some config file
>>> (preferrably xml) and being able to provide a back functionality in
>>> addition to the enter, exit and cancel in the dialogcontroller.
>>
>>
>>
>> Interesting ... I had next() and previous() methods in my original
>> design for this API.
>>
>>
>>> This
>>> would make creating wizard like dialogs very easy and provide a way to
>>> navigate through the dialog in both directions.
>>
>>
>>
>> The reasons I don't have next() and previous() at the moment are as
>> follows:
>>
>> * Wizards tend to have a sequential flow (forwards and backwards)
>> but that isn't the only kind of dialog that needs to be supported.
>> The methods would go unused in some cases.
>>
>> * Manually implementing next and previous functionality (as I did in
>> the "use cases" example app) is so easy to do that it's hard to
>> see much benefit from having the methods directly implemented.
>>
>> * A generic "next" or "previous" method would have to be aware of
>> all the possible logical outcomes, and this list would have to be
>> updated every time a new step was added. In the current approach
>> an event handler only has to know the outcome ot get to the
>> adjacent view, and isn't affected when new steps are added (unless
>> it is adjacent).
>>
>> Does that make sense?
>>
>>
>>> Taking the
>>> synchronization token pattern in account it might even be possible to
>>> provide the same data when the user presses the browser back button.
>>
>>
>>
>> I think this is going to require some assistance from the state saving
>> machinery that JSF provides, but it would be interesting. It might
>> also be that the user still expects the state information to be the
>> most current state, just like they would get from a regular "previous"
>> button.
>>
>>
>>> The advantage of a flow control is that the session can be cleaned
>>> fairly easy when skipping from one dialog to the other and information
>>> is not unnessecarly stored.
>>
>>
>>
>> My current thinking is that we want the ability to have more than one
>> active dialog, so you can "push" from one dialog to another, then
>> "pop" back out. That's why I made it the dialog's responsibility to
>> clean itself up.
>>
>> I don't like the fact that the dialog has to know the attribute name
>> it is stored under (in session scope), but haven't figured out a way
>> around it yet.
>>
>>
>>> Regards
>>>
>>> Stefan Langer
>>>
>>>
>>
>>
>> Craig
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org