On 1/6/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > On Fri, January 6, 2006 1:01 pm, Michael Jouravlev said: > > Rrright. You want to save on network bandwidth by validating in > > browser. At the same time we have Ajax "suggest"-type junk growing in > > popularity, where server is pulled each time a user hits a button. > > Well, not *each* time a key is pressed... look at the code for Google > Suggests and you will see they do a really cool thing where they throttle > the number of requests based on how fast you are typing. It's not a 1:1 > call per keypress unless you are typing really slow. > > (My own AjaxTags example doesn't do this, but hey, Google has Ph.D's to > spare whereas I don't have even one!)
The above was not meant to be an attack on you (do you have suggest-type thing?) ;-)) Google has also bandwidth and number of connections to spare ;-) > > Nah. Imho, client-side validation should be minimal. Empty/non-emty, > > proper length. Maybe some simple data conversion check like is it a > > number or a valid email. Yes, it is not DRY and redundant because the > > final validation is done on the server anyway, but user's Athlon 64 > > needs some code to chew. Everything more complex than above, including > > custom error messages, inter-field dependencies, etc is checked on > > server. It will be checked on server anyway, because user's browser is > > in the open, whoever can change the validation rules or turn them off > > or turn Javascript off. > > Best practices have dictated for a long time that any validation that > occurs on the client should also occur on the server. But, the more you > can pull off on the client, the more responsive and user-friendly your > application will usually be. ...and the larger the Javascript file gets. If validation still has to be done on server, how do you compare (1) one-time (hopefully) load of a large Javascript validation file for client-based validation, with (2) going back to the server and updating a relatively small page region without full page reload? [ I have my Ajax now too, :-) ] The latter is simpler for me. Is it better? It is not much worse than former I would say, but a lot simpler, and I do not have to duplicate Java validation in Javascript. > If you combine an ActionForm with an Action, what happens if you want to > give that combined object session scope? Would you then store the entire > thing in session? I would assume so. That seems like a (potentially) big > waste of resources. Why? The code and class definition are loaded only once. Where the resources are wasted? > > Advertising ActionForm as a request parameter holder in Struts best > > practices is a mistake imho. It can be used as an input/output buffer, > > as this kind of layer that you talk about. Apparently, it should have > > session scope ;) and implement Serializable. > > I would make the argument that session-scope for an ActionForm is the > abomination. There should be something else, and I'm not sure I know > what, that gets stashed in session scope. I am pretty happy with ActionForm in session ;) > If an ActionForm is thought of > ONLY as a buffer as you say, a DTO between presentation and control > basically, Struts seems a lot cleaner all of a sudden. Um, a lot cleaner (1) if it contains only request parameters per-request as it is bieing recommended to be used now, or (2) if it contains I/O data between requests during conversation with a user, including wrong input values and error messages? > Of course, that > then leaves a lot of questions about how you persist user entries and > such, and I admit I don't have a good answer there. The main drawback of session-scoped ActionForm is that I can have only one of each kind. Does not work well with several windows opened. Couple of years ago I was doing a little different, i had a list of session-scoped presentation objects that contained I/O values and errors. So I could have one action form and several session-scoped I/O objects related to it. But then I decided to abandon this, too complex to manage and users don't usually open secondary windows themselves. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
