struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <>
Subject Re: [shale] Re: Struts Shale
Date Tue, 18 Jan 2005 15:00:23 GMT
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

'nuff said.


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
> <> 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
>>> <> 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  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:
>> For additional commands, e-mail:
> --
> ------------------------------
> "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: For
> additional commands, e-mail:

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

View raw message