On 1/6/06, Ted Husted <[EMAIL PROTECTED]> wrote: > On 1/6/06, Dave Newton <[EMAIL PROTECTED]> wrote: > > Doesn't it just need validation info rather than model knowledge (you > > listed validation constraints/msgs in your original list, which is why I > > can't figure out why it needs any more info). > > If we consider the target type to be a validation constraint, then we > are stating the same fact twice. Target type is an implicit validation > constraint. Other domain constraints might be a range of values within > the target type. And, of course, in practice, checking subranges > usually begs converting the input to the target type.
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. 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. Client validation is just a cherry on a cake, but I don't want this cherry to be too large. > Ideally, formatting and conversion should be part of validation, so > that we don't do any of these things more than once as part of the > same request/response. But, all this is something that we also need to > do with *any* presentation layer, not just a web front-end. For > example, we should be able to run independant unit tests (another > presentation layer) that demonstrate that input and output are being > formatted as expected. > > These concerns, and many others, beg the existing of a layer between > *any* presentation layer and *any* business layer. I think we've been > trying to create this layer with efforts like XWork and Commons Chain. > A controller layer between the view and model that handles concerns > like conversion/formatting/validation, and even logical navigation, > but that is independant of a particular presentation layer. 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. I also store error messages in the ActionForm, so my errors correspond to a page (or a component on a page). I guess I could go further and have error messages per property but this is too much hassle. 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. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
