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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]). 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
