The idea of having Struts generate JavaScript code to run on the client
makes me uncomfortable. It just seems like a whole can of worms you wouldn't
want to get into.
Not all browsers support JavaScript, and not all users (are allowed to) have
it enabled. I wouldn't be surprised if there are implementation differences
too. How would this be handled? By Struts "knowing" all of this, or by the
implementor "knowing" what Struts needs to know? When a new version of
something appears, where do the changes need to happen to support it?
It just seems to me that it might be better to have Struts focus on doing
its thing at the back end, and doing it well, rather than branching off this
early into another code base that runs on a different platform (i.e. the
JavaScript that will run on the browser), with its own set of debugging and
maintenance issues.
My 2 cents...
--
Martin Cooper
Tumbleweed Communications
----- Original Message -----
From: "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
To: <struts-dev@jakarta.apache.org>
Sent: Monday, September 04, 2000 10:45 AM
Subject: Re: [PROPOSAL] New Struts Configuration File Format
> "Lacerda, Wellington (AFIS)" wrote:
>
> > I agree that server-side validation is necessary, but a web system is a
> > distributed system, and we can't just cut that advantage.
> >
> > I think I got the concept, but how would you differentiate which field
> > validator should be called by which field and WHEN ?
> > All this information would go to action.xml ? In a system with many
pages
> > (say, 100 jsp forms) the action.xml file will grow too big, won't it ?
> >
> > Also, we must avoid become too cryptic. Remember that those pages will
be
> > read by non programmers too, and designers and web masters will have to
have
> > an idea about what they will be dealing with.
> >
>
> I think we can have our cake and eat it too, if we adopt something like
this:
>
> * Add a "validation" attribute to the <property> element of a form bean.
>
> * The validation value would be a set of conditions (perhaps
comma-delimited)
> that
> should be checked ("required", "must be a date", "must match a format
pattern"
> ...).
>
> * The server-side code in ActionServlet would check all of these
conditions
> automatically (no code required in the ActionForm bean itself). It will
> return
> directly to the input form if these conditions are violated.
>
> * The form tags would either optionally or automatically generate
client-side
> JavaScript code to check the conditions that can be checked there.
>
> * Interaction with a ValidatingActionForm would need to be defined.
Perhaps
> we should call it's validate method with the set of error messages we
have
> already accumulated, so that the user gets them all at once?
>
> > Wellington Silva
> >
>
> Craig McClanahan
>
>
|