On 7/28/05, Ed Griebel <[EMAIL PROTECTED]> wrote: > Rick- > > I'm faced with this same problem on a new project and have been > thinking along these same lines. What kind of issues have you run > into?
I am interested too ;) > The kind of things that I see being a problem is specifying > which sets of actions are associated with what items in a session, and > which sets of actions are resumable and which ones clear state if one > navigates away from the path. I think it should be pretty easy. An action mapping can belong to one or several subsessions. This can be defined in <action> element of config file. In my case ;) I have pretty coarse actions, I base them on DispatchAction (actually SelectAction, but whatever). One action contains a component, and serves all requests to this component, and displays all pages of this component. It can be a Login component, or CRUD component, or a wizard. So, correlating a component to action to data that is used by it is easy. In some cases, say in one version of CRUD sample, I may have two actions which work with the same set of data. In this case both actions would correspond to one subsession. Once I load any other action which does not correspond to this subsession, I can safely remove the CRUD action form with all stuff sitting in it from the session. One line of code. Ok, two lines ;) On next request RequestProcessor will call RequestUtils.createActionForm which will create fresh instance if needed. Voila. Note that this works even with Back button, because I use "no-store" pages, which are reloaded on Back. Reload calls actio outside of subsession, and subsession is removed. This will fail only if a user will go to a completely different site, so at most application will keep *one* object hanging in the session. I don't care ;) Note I've purposefully avoided mentioning the "F" [flow] word. One of my design ideas (which probably are stolen from someone whom I've purposefully avoided mentioning too) is that flow is not needed. Each component like login, or menu or subscriptions or language selection (these are from MailReader) should be totally independent, but stateful. Flow only has to be supported for small sections, like a wizard, which fits fully into one action. Why application flow should not be needed? Because flow ties your hands and does not allow to easily develop reusable components. Say, you have flow: welcome -> choose language -> login -> main menu -> subscriptions. What if you get to main menu, then go back, log out, and then navigate to main menu again? Should flow control engine throw an exception, notifying you that you broke flow? Nah. Instead, main menu simply checks can it be shown or not (logged in or logged out). If it can, the it shows itself, if not, it goes to login page. Generic application flow is a bad thing, small action-scoped wizards rule! ;-)) Michael. -- Struts dialogs, components, controls, wizards and other good stuff http://struts.sourceforge.net/strutsdialogs --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
