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!) > 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. Of course there is that fine line of not having business logic on the client (i.e., should an entered dollar amount be checked against a mutual fund load table on the client? Probably not). > Client validation is just a cherry on a cake, but I don't want this > cherry to be too large. I would argue the bigger the cherry, the better. The application will be better for it in most cases. Yes, there is more to consider when you do that, but the benefits outweigh the negatives IMO. But, I always give the cherry to my wife off my sundaes anyway, I'm not a fan of cherrys to begin with :) > Actually, if we talk about Struts, ActionForms is the basis of this > layer, I only would prefer them to be combined with Actions. There are > properties aka getters/setters, so setters can always check what is > being passed from browser. I am an old school in terms that I usually > don't use dynaforms, instead I define an ActionForm having dual typing > either by having String-type and strong-type property right in the > form, or by having String-type property in the form for display and a > nested strong-type property from a business object. Yes, I would like > this to be automated and JSF managed beans look nice in this extent. The idea of an ActionForm was a great concept to begin with, and it seems like many people don't see the benefit (not saying you Michael, just making a general statement). Think about the case where you want to slap a VB-based front-end over a Struts-based application. When you have an object that serves as a string-only buffer between the presentation and the rest of the application, you have effectively abstracted away any data types differences between how the presentation is built and how the rest of the app is built because strings are, for all intents and purposes, universal. If you try and go directly to native types, you have to deal with the fact that maybe VB doesn't have a BigDecimal type for example. The conversion, assuming one is possible, has to occur at an arguably inappropriate time. I suppose the fact that not too many people have ever had to change from JSP to VB has something to do with this :) 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 wouldn't you rather have an object that contains almost nothing but data and store that? (I'm playing devil's advocate here... I haven't fully decided whether I agree with the basic premise or not). > 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. 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. 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. > Michael. Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
