I don't know if it will be as simple as you would
like, but Struts takes a lot of work away for you.
There is a lot of work planned for Struts 1.1 which
will save even more time.
Here are a few packages that are posted. There are a
lot of other resources posted on Ted Husted's site.
http://www.husted.com/about/struts
Validation Package
http://home.earthlink.net/~dwinterfeldt
There is a JDBC example in the validation package that
doesn't confirm a save, but does confirm a delete.
Mapper (validation/transformation package)
http://www.husted.com/about/struts/resources.htm#extensions
Generates Action and ActionForm based on a JSP page.
http://www.husted.com/about/struts/StrutsCodeMaker.htm
David
http://home.earthlink.net/~dwinterfeldt
--- Jonathan Fuerth <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 27, 2001 at 09:27:13AM -0700, David
> Winterfeldt wrote:
> > The ActionForm is considered to be a container for
> > holding and preserving the information the user
> has
> > entered. So you don't want to reject any data at
> this
> > level because if the validation fails you want to
> > return exactly what the user has entered. So most
>
> Aha! Ok, that makes a few things clearer in my
> head. Unfortunately,
> it also raises some new questions. :)
>
> For instance, how would you go about modeling this
> generic and (I
> imagine) common web-application scenario:
>
> -A server-side validated form is presented to the
> client, who is
> expected to make mistakes.
> -The server catches the mistakes and presents the
> previous values to
> the user, flagging the ones that need to be
> re-entered.
> -Finally, the user gets everything right. A page is
> presented to the
> user which summarises the input, along with an
> "accept" or "cancel"
> choice at the bottom.
> -The user gives the go-ahead, and the correct
> information is stored in
> a JDBC-accessed database.
> -Later, the user (or other interested parties) will
> be presented with
> this data.
>
> This is essentially what I've been trying to figure
> out for a year now
> (when I first got into servlets). In my experience,
> the fields in the
> form will change fairly often, as will their default
> values and
> acceptable ranges. What I'm aiming for is to be
> able to perform this
> sequence of events for any given set of
> database-stored data, while
> only specifying the labels, datatypes, defaults,
> accepted ranges, and
> underlying SQL statements once (and hopefully in one
> place, but that
> may be too much of a stretch).
>
> Have you (or other struts users) managed this feat
> yet? I'm very
> interested in anything anyone has to say on this
> topic.. It's become
> an obsession (since my full-time job is to design
> and implement
> java-based, RDBMS-backed web applications).
>
>
> > * When the exception/validation happens in the
> setter,
> > you can't do things that depend on other fields.
> Like
> > this field is required only if another field is
> filled
> > in.
>
> Ok, excellent point. That JavaBeans constrained
> property model kind
> of relies on an AWT/Swing-type GUI, where this isn't
> an issue. As
> you've observed, it's certainly an issue in a web
> application.
> Dependant fields would have to be informed whenever
> their dependencies
> change value.
>
> > Also the current system isn't able to handle an
> > exception being thrown during the auto-population
> of
> > the ActionForm from the request.
>
> Ok. It sounds like I'll have to make a similar (but
> different) bean
> to each FormAction bean which does the actual
> database manipulation
> and stuff. That throws me off my little quest for
> the
> single-specification-of-everything-in-the-form
> paradigm. :)
>
> Thanks for your reply.
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
