Hi again Kevin,
Cubed comments intermixed ;).
Kevin Duffey wrote:
>
> Hi,
>
> I'll add comments to comments to my comments. ;)
>
<snip, snip, ...>
> >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.
I agree that client-side validation allows for some nifty things to be
done without requiring a round trip to the server, but following
Murphy's Laws I created my own rule "if you really want users not to do
something, make it IMPOSSIBLE to happen." So even if you check
JavaScript is on in the first page, or even in each page, JavaScript
could be turned off, or the JavaScript engine could crash, just before
sending the request so even though you can implement client side
validation to help the user, you should, IMHO, always implement server
side validation to enforce business rules.
> >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?
As I said, it all pretty much boils down to a matter of taste. If you
follow the "state machine" approach for the whole process, you would
probably use one Bean, which would implement the state machine, and then
in your action classes you would simply call the appropriate methods
with the appropriate parameters so I don't think using just one action
class would make it so difficult to understand. On one hand, using ONE
action class allows including more steps just by changing this class,
event though it forces you to recompile this class and it could become a
giant switch. On the other hand, using MULTIPLE classes allows you
add/modify steps without recompiling the other steps but it forces you
to specify the url->action class mapping for each step and coordinating
different and independent classes to perform one process could become
more difficult. I can see no definitive answer, it pretty much depends
on the the number of steps, the complexity of the steps/overall process,
the desired flexibililty on the number of 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.
>
> 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.
Agreed. But here it was more a question of ease of development/freedom
for the designers(UI) against ease of development for the
developers(programmers). If you give too much freedom/power to one of
the groups, the other could be rendered less productive.
Thanks for the input,
Dan
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
===========================================================================
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
