Sometimes it is preferrable to have a 'generic dialog' page, rather than messages at the top of the screen. This isn't an either or situation, in our apps, both styles are often required and used.
We implemented a solution that basically implements a 'navigation stack', as the needs of our app's in this area get very complex. But basically this allows us to not only dynamically determine where to go when 'ok' is pressed, but to stack these up for 'nested operations', thereby returning the user thru a particular workflow (the back button and history are not suffiecient for this purpose) One other point - it is NOT ALWAYS bad practise to have workflow info come from a source other than the struts config. In fact, in many systems this is an absolute requirement. Our apps have some very complex workflow, and in these situations the struts config is not suitable to model the interactions required - and we wouldn't want to put it there anyway, because it is inherently dynamic ie it can and does change from one time to the next. So to attempt to model this kind of scenario in the config would be folly. However, I agree that for most situations it IS good practise to use the config for this info. Just remember that there are no hard rules here. So the upshot is that implementing a dynamic 'navigation stack' (incedentally, without hidden fields) can solve all the problems you have with a generic dialog scenario, or more complex workflow - where the flow is dynamic. Hope this helps - if you need more info then contact me. We have implemented this in a production enviornment successfully. Thanks Ghoot > -----Original Message----- > From: Keith [mailto:[EMAIL PROTECTED]] > Sent: 15 February 2002 11:45 > To: Struts Users Mailing List > Subject: Confirm Style (was: Request: Property vs Attribute) > > > maybe heading off topic - forgive me - but I want struts > systems to be well > designed! > > The web is so darn slow - for repetitive use system > confirmation/dialogs are a > real pain. I'm not a designer but I feel it's best to take > the user to a useful > page & put your message at the top of it. > eg. in Action after the update > request.removeAttribute("userMessage"); // make sure only 1 message > request.addAttribute("userMessage", "well done - we have > saved your details"); > > then at top of jsp's. > <logic:present name="userMessage" scope="request"> > <bean:write name="userMessage" scope="request" /> > </logic:present> > > or better still use the new Messages tag. > Keith. > > --- Andreas Mack <[EMAIL PROTECTED]> wrote: > > On Fri, 2002-02-15 at 02:19, Ted Husted wrote: > > > > I have a question along these lines: > > Quite often I have thing like an acknowledge page, very much > > like an Ok Dialog: "The password has been changed successfully. > > <html:submit>OK</html:submit>". I'm toying with the idea of > generalize > > this by having an "OKAction" and an okdialog.jsp where I parametrize > > or attributize the message and the forward (yes, this is > bad, routing > > outside of struts-config.xml). > > > > It works, but only sub-optimal, because to return to a specific page > > "/userdetail.do" requires the uid field. Somehow this > should be within > > the generic okdialog.jsp. I'd like to have a collection of > parameters > > set which are dynamically added to the okdialog.jsp in > hidden fields, > > but hidden::name/property seems to be "static". Any hints > here ? Am I > > down a wrong road ? How do others do these quite generic dialogs ? > > > > Thanks! > > > > -- > > Andreas Mack <[EMAIL PROTECTED]> > > mediales. GmbH http://www.mediales.de > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > __________________________________________________ > Do You Yahoo!? > Got something to say? Say it better with Yahoo! Video Mail > http://mail.yahoo.com > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
