Hi,
I'll add some comments of my own.
Kevin Duffey escribi�:
> Hi,
>
> I'll try responding. ;)
>
> >* Would multiple forms/pages require a different validation bean for each
> >page? (This assumes that you want to validate the user's input on a per
> >page basis, rather than, or in addition to, when he/she chooses the finish
> >option.)
>
> Actually, I prefer client-side validation using JavaScript. I have seen some
> people say to do both or server-side, but frankly, client-side eliminates
> the need for server cpu cycles to validate entries. If you validate them
> properly on the client with JavaScript, you know they are correct when they
> get to the server. I think the exception is if during trasit something gets
> messed up, a lost packet or something. I have never seen that happen and am
> pretty content with using client-side validation.
Eummm, actually I always recommend and implement doing it the other way
round (I'm
sorry Kevin ;) ).
If your browser doesn't execute Javascript (incompatible versions, user
disable it,
javascript engine crashed...) all you efforts of client side valiation
are gone.
So we always start implementing server side validation first and
then as an extra if the communications are slow, we implement client
side validation.
If you rely only in client side validation, you might get very ugly
behaviour
if some of the above conditions occurr.
> But, if you were to do server-side, I would definitely use page per page
> validation! Imagine 4 or 5 forms and your sent back to form 1 because of one
> bad entry. Then you have to code in on that page a "finish" button, and on
> every page, for that matter, so that they dont have to submit the other
> forms that may be correct. I would break it in to an action class per page,
> and if you have multiple actions for a complete set of forms, they can still
> all reference the same one entity class (JavaBean most likely..or EJB). By
> storing the entity in the HttpSession, it stays alive all throughought. Then
> at the end, you process the data, store it, whatever, then remove the bean
> from the HttpSession.
Here I agree with Kevin :). I would use "per-action" validation as it is
quite
unpleasant for the user to be told that he made a mistake in step 1 when
he
submits the whole data after 5 or 6 steps. I see this kind of processing
as
a state machine, so you cannot proceed to the next step/state unless you
full
fill the requirements on the previous steps. It�s much easier for me to
think
about it that way, than trying to imagine all the possible combinations
of going from
step x to step y and what I have to do in each case. But that's a matter
of taste.
> >* Choosing the finish option would (naturally!) post to the
> >UserRegistration.do according to good model 2 design. Is it OK to have the
> >back/next "events" directly navigate to the previous/next .jsp page? (I
> >don't want to have to create UserRegistrationStepOne.do thru
> >UserRegistrationStepTen.do! (Do I?)
If you have to perform some logic, like checking if the user has
performed all the
necessary previous steps to do what he wants to do, I'd still go through
the controller
- action - view pattern. So I' create UserRegistrationStepOne ....
UserRegistrationStepTen
or use just UserRegistration?step=1 to UserRegistration?step=10 which is
easier to mantain.
> I do. I have a JSP page per form that is to be displayed. And I have an
> action per form. You can have multiple forms submit to the same action, but
> then you'll need some sort of hidden command code system to figure out the
> specific action to take.
Exactly. You can also use the same JSP for different actions which is
one of the advantages
of using model 2, the URL looks different but the JSP is the same but
after performing a
different action.
> However, usually no processing other than validation and storage in the bean
> and display the next page is done between steps. Not always the case though.
> For example, on our site clients choose an option, and depending on which
> option they choose, the next page reflects that option. Not necessarily the
> page name or anything (although that certainly can be done too).
>
> >* Finally, doesn't this lead to too high a degree of coupling between the
> >view & the controller(s)? Or, what I mean is, haven't we prevented our page
> >designers from exercising their creative freedom to place which fields on
> >which form, since that will always require "back-end" coding changes?
I get your point in here and I agree with you that there's a certain
degree
of coupling between view and action. But as the http is a connectionless
protocol this problem is not easily avoided. One possible solution would
be to use the same action/bean throughout all the steps and then check
on
every request to see what parameters have been set and try to modify
those.
You would have to check every time all the possible parameters that can
be
modified in all the steps an check/set them in a certain order but this
way
you could let your designers put each field on the form they like, as
long
as they follow the defined logical order (for example they can't put the
"choose number of items" field in a form, before they have chosen the
item
itself...) If all this checking/setting is worth the freedom you give to
your developers depends on many factors so I would consider it on a case
by case basis.
Just my 2c,
Dan
> Ideally your web person can use Taglibs (JSP 1.1) or JavaBeans in any way
> he/she likes. For example, as I said even if you use one action per form,
> you would most likely use the same JavaBean amongts the different action
> classes to store all the form input (and output), so that each of the JSP
> pages use the same bean for display as well. Thus, unless the name of a
> method or property was changed on the back end, the web developer pretty
> much has the freedom to move the dynamic content around at will. Its more
> likely (I think) that the developers would make changes and tell the web
> folks the change and not the other way around.
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
