"Jakkampudi, ChandraseKhar" wrote: > I dont think this approach will work if you need transactional control > across the different "tabs" of the wizard. For example if it is a > registration wizard that collects contact info and billing info on different > tabs, using different forms and commiting to the database will leave you > with a lot of problems.
Perhaps I do not understand what you are saying, but Expresso does this all day every day, and it has worked like a charm for (....years?). When you create a registration app with webAppWriter, for example, you can have any number of tables as registration requirements, and each have it's own CRUD views separately maintained, or alternatively, one set of MVC CRUD views for the whole thing, while still maintaining each table as a separate registration requirement. If you don't believe it, go to webAppWriter.com and create a registration app. Takes about 10 minutes, plus a few minutes to wait for the zip file in your email. There are also tutorials on how to set up a quick Expresso test installation, so you won't mess with your existing apps or app server. Results, not theory about what won't work and why. But then again, if you can shoot holes in it, that is fine too. > We use a single form and store it in the session rather than the request > eliminating the need for the hidden variables as proposed by somebody else. > > I notice that this is what you originally proposed. This approach works very > well for us (thought there is a bit of clean-up at the cancel or submit) > > -----Original Message----- > From: Pete Carapetyan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 05, 2002 10:22 AM > To: Struts Users Mailing List > Subject: Re: Wizard Interface question > > Pete Serafin wrote: > > > I am trying to develop an interface for entering data for one object > > across multiple forms as in a wizard interface. Can anyone describe the > > best way to approach the design of this type of functionality. > > Doubt that there is any one right way, but webAppWriter keeps everything in > a > database, and uses many different forms, one for each of the CRUD operations > for > each of the three tables it maintains (App, Tables, Fields). Lots of forms, > but > each only has to do one thing. > > This approach allows anyone to start or stop anywhere within the process, > and > their state is always intact and can be picked up at any stage within the > process. > > Oddly enough, this same thing is true of each of the applications it > produces, > though I never thought of them as Wizard forms before. To be a wizard, all > it > takes is some result that happens after the data is sucked in. > > It would seem that this is much more scalable than sticking everything in a > session, but it was also a lot easier for me to do this way. It seems to be > the > way Expresso is designed to work. Plus, users would go nuts if they had to > get > everything done in a session. > > Does it work ? Has about 9 months without a problem, though only since > posting on > the struts resource page has it been getting heavy use. > > > I was > > thinking that the actionforms would be stored in the user session until > > a submit to database or a cancel is requested. Is this the best way to > > handle this? Thanks, > > > > Pete Serafin > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > Pete Carapetyan > http://datafundamentals.com > Java Development Services > > Open standards technology for commercial profitability > > -- > 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]> -- Pete Carapetyan http://datafundamentals.com Java Development Services Open standards technology for commercial profitability -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
