Hi,
I'll add comments to comments to my comments. ;)
>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.
No problem Daniel. Actually I agree. I forget on our site we "require"
NS/MSIE4 or later, JavaScript and Cookie support to use our site. We are a
B2B site, and have a small number of clients at this time. We have had no
problems enforcing this other than the occasional (or frequent) call to
explain how to enable JavaScript and/or cookies. The worse case scenario is
those sitting behind a firewall with cookie support turned off. Thus far, we
have not turned to URL Rewriting, so we force their admin folks to turn on
the cookies on their side.
But your quite right, on most sites I would not rely on client-side
validation. Its sad to think of the number of incompatible possibilities
between browsers, even though most are MSIE or NS 4 or later these days. I
do like the client-side ability to immediately show an error next to a field
without a round-robin call to the server to figure this out.
>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.
Curious Daniel...why use the ?step=1.. that is like the "hidden command"
sort of deal, but instead using a request parameter directly. I thought the
idea of this controller/action framework is to allow a single action class
per form to easily maintain/debug problems, among other things. Would you
use a single action class for each form, even on multiple page forms? I am
asking because we have mostly multiple page forms on our site, and each page
is built based on the previous pages input..so I figured an action for each
form would be better than one action handling multiple forms. Especially
because the controller servlet calls just the perform() method. I would have
to have the perform method figure out the request value and maybe do a
switch() or something. Although..it leaves my mind thinking..is it better to
use one class, a switch statement based on some "step" #, and only have one
class loaded instead of X classes loaded for X steps? Again for me this
boils down to the "right" way to do it based on development maintainability
versus performance/resource allocation. By having multiple classes loaded,
you use more memory and resources, but you can more easily debug the
specific action that is having the problem. Ofcourse, using a single class
with a switch based on the step #, I think its pretty easy to arrange each
case X: to call a method in the one class and you can easily find the method
based on the step # being the problem. What do you guys think?
>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.
Agreed. I still believe my preference is "ease of development" even if it
means more classes loaded. I would rather make it easier for myself to go in
and fix a bug, make a change, etc then make it slightly faster. We can
always throw more hardware at the problem if need be. Hell, we are using a
dual PIII500Mhz 1GB RAM web server already, which from what I gather can
handle oh..about 4 million requests a day or so! Seeing as how in our niche
of the business world if we had EVERY possible person on boths sides of our
B2B hitting our site for the entire year all at one time, we could still
handle them! So, at least for us, maintaining the code is more important
than the performance gain. I would always opt for this..computers are
getting ever faster and I am pretty sure most sites could handle thier needs
and be more productive in this manner.
===========================================================================
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
