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.
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.
>* 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?)
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.
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?
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
