struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Carapetyan <p...@datafundamentals.com>
Subject Re: Wizard Interface question
Date Tue, 05 Feb 2002 16:43:42 GMT
"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:pete@datafundamentals.com]
> 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:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
> --
> Pete Carapetyan
> http://datafundamentals.com
> Java Development Services
>
> Open standards technology for commercial profitability
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>

--
Pete Carapetyan
http://datafundamentals.com
Java Development Services

Open standards technology for commercial profitability



--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message