Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41ECC7EC.2040500@bettsockentraeger.de>
Date: Tue, 18 Jan 2005 09:25:16 +0100
From: Stefan Langer <myfaces@bettsockentraeger.de>
Reply-To: myfaces@bettsockentraeger.de
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: craigmcc@apache.org
CC: dev@struts.apache.org
Subject: [shale] Re: Struts Shale
References: <41E78287.3080502@bettsockentraeger.de>
 <f8b39ace0501140826112e9a13@mail.gmail.com>
In-Reply-To: <f8b39ace0501140826112e9a13@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
> <myfaces@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