This implies that you would specify the class for your DTO or value bean that you want BeanUtils.CopyProperties to put all the data in. You would have to specify this in the configuration validation.xml so that struts can do the validation/conversion and return on failure to your mapping's input.
Secondly regarding the speed factor, it is common practice recently to code to a possibly slow design, but throw hardware at it to compensate. However this paradigm perhaps doesn't exist in China for example or India where hardware is relatively more expensive compared to programmer salaries. I don't know. Personally I would be unsatisfied if my page didn't return from submit after 2 seconds, but then I generally have hardcore hardware.
I think the client-side validation is currently only for javascript because nobody needs it for anything else yet, but presumably client-side validation could be produced in any scripting language. VB script, for instance ( ducking and running ;) )
Adam
On 08/15/2003 06:24 PM Yansheng Lin wrote:
You misunderstood me. I didn't presume that all my clients will run javascript(that's one of the issue addressed by the validator framework), but most of them are anyway(aren't u?). For those ones who are running js, they wouldn't have to wait for 5 seconds for an error msg telling them that they forgot to type in a required field. They can take advantage of the client-side validation provided by the validator framework and get a pop-warning instantly. For those people who don't have their javascript enabled, the validator framework server-side validation guarantees that the input will get checked.
Speed, man:). That's one of the main issues with the validation scheme you
proposed.
-----Original Message-----
From: Adam Levine [mailto:[EMAIL PROTECTED] Sent: August 15, 2003 8:59 AM
To: [EMAIL PROTECTED]
Subject: RE: validation philosophical question
and.. the follow up..
If you have the validation only in the presentation tier (reiterate: BAD design), you're going to have to duplicate that validation for all other presentation layers that may access your business tiers. Replication of work.. hrmm.. sounds like a bad design pattern to me.
From: "Adam Levine" <[EMAIL PROTECTED]> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: RE: validation philosophical question Date: Fri, 15 Aug 2003 09:45:57 -0500
The fallacy in your logic is that you presume *all* clients will support javascript, and thusly will run the client-side validation routines. If you rely only on this happening, and don't do a double-check in the business layers, you're asking for trouble. caveat emptor.
From: "Yansheng Lin" <[EMAIL PROTECTED]> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Subject: RE: validation philosophical question Date: Fri, 15 Aug 2003 08:32:45 -0600
<quote>
When both JavaScript and server-side validations are being used, the properties
end up being cast three times, twice by the Validator and a third time when it
finally gets to the business tier.
</quote>
No, I have to disagree. Suppose there is a required field and user didn't enter
anything. With client-side javascript enabled, there is no submit action if
user forgot to input something. That's only one validation in the case of
error. Suppose there is no error, the javascript validation will run on the
client machine when he submits it. Cast or no cast, it's fast since it's on the
local machine. Then the server-side validation runs when the request comes in,
which you are supposed to do anyway.
I am not sure why you think there should be a third time when it gets to
business tier. When it gets to the business tire, the data should be at least
'legal'; i.e., 'insertable' to the database or whatever. Those things should be
taken care of once you started business rule processing or the database itself
with the constraits set.
-----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 3:45 PM To: Struts Users Mailing List Subject: Re: validation philosophical question
A "hidden cost" of using the Struts Validator is that most of the validations are implemented using standard type casts. When both JavaScript and server-side validations are being used, the properties end up being cast three times, twice by the Validator and a third time when it finally gets to the business tier. Though, I have absolutely no idea what how much these type-casts actually cost, and its quite possible that something like a regular expression would cost more.
The Struts Validator is a convenience, but I wouldn't call it a panacea.
I don't have anything like this, but it seems to me the idea solution would handle transformations and validations in the same transaction, so nothing would be wasted. If the transformation succeeds, you'd be able to use the transformed variable, and not have to transform it again later. Of course, there should be support for script generation for those that need it (as we have now).
This implies that the ActionForm might not do the server-side validation itself, but that another component in the business layer, that shared the validation.xml and application.properties, might do both the validation and transformation below the Struts horizon. This hypothetical component would then return Commons Resources messages back to Struts, which would in turn expose these messages to the pages by placing them in the request context (as we do now).
Speaking to the original question, I would say that the logical (even only) place for *all* the validation has to be on the business layer. Since you not only need to know, for example, that a login has the proper form, but that it exists. And so forth.
In general, most developers prefer to centralize access to the business layer in the Action. (Though, aside from philosophy, there's nothing to prevent you from accessing the business layer from the ActionForm's validate or reset methods.) What you might want to do is define a validate method in your Action that uses the same signature as ActionForm validate. You can then have your Action call then and return to input should any messages be returned.
-Ted.
Yansheng Lin wrote:
> No, that won't do for high volumn traffic sites. It's too costly.
>
> The combination of the client-side and server-side gives you
> reliability and speed, and only validator framework does that.
>
> Btw, I agreed mostly with what you said....
>
> Thanks!
>
>
> -----Original Message-----
> From: Adam Levine [mailto:[EMAIL PROTECTED]
> Sent: August 14, 2003 11:42 AM
> To: [EMAIL PROTECTED]
> Subject: RE: validation philosophical question
>
>
> If you reread my post, you'll see the validation happens only in one
> spot,
> and that's in the business logic area. This keeps the same validation
logic
> present, regardless of the presentation layer. AFAIK, the Validation
> framework Struts provides should only be used as a cursory check (is this
> box filled in, is this a number) for use within the browser portion. And,
> again, this ties it only to the presentation layer -- which means if you
use
> another interface, ie wap/braille/DTMF/IVR, you're going to have to
> duplicate the validation for that layer.
>
>
> From: "Yansheng Lin" <[EMAIL PROTECTED]>
> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
> Subject: RE: validation philosophical question
> Date: Thu, 14 Aug 2003 11:29:11 -0600
>
> Agreed mostly, but...
>
> what happens when you want to change some validation rules? You have
> to
> change
> two or more places instead of one if you choose to use other validation
> methods
> instead of keeping everything inside the validator framework. The goal of
> validator framework is to eliminate these redundancy. Making sure
> everything is
> kept inside of the config file, you only need to modify one place.
>
> - Yansheng
>
> -----Original Message-----
> From: Adam Levine [mailto:[EMAIL PROTECTED]
> Sent: August 14, 2003 10:43 AM
> To: [EMAIL PROTECTED]
> Subject: Re: validation philosophical question
>
>
> My personal preference is there should be as little reliance on the
> front-side as possible. I personally hate little JS boxes popping up
> at me "this entry isn't right.. fix it!", and much prefer a
> submit-correct cycle with quiet, unobtrusive indicators showing me
> what I need to change.
>
> If you insist on front-side validation (which, yes, can make the user
> experience better), you should ALWAYS have backup/duplicate
> server-side validation.. otherwise, what happens for the
> browsers/users who 1) don't have JS enabled, 2) don't have JS
> functionality ?
>
> As for where the appropriate place is business side.. That's dependent
> upon your system design. My Actions merely act as a gateway to
> business objects that handle data validation. If the data isn't
> right, I aggregate a list of custom exceptions
> ('UserLoginNameAlreadyExistsException') to be handed back to the
> Action caller, and return to the caller w/o performing any more
> business logic. The action caller checks that list for entries, and
> accumulates form field error messages appropriately, and then
> forwards/returns (actionmapping) to the entry page.
>
> if the business logic generates no custom exceptions, i perform the
> business logic as appropriate (ie, updating/creating an entity bean,
> and return an empty list to the caller.
>
> if i have a system level problem (EJB/JNDI/something systematic that
> just doesn't work), I throw a custom generic exception (ie,
> UserCreationException) for the calling process to catch. the action
> can then populate the errors with a generic process error message
> ("there was a system problem trying to create your account. try again
> or send an email to....").
>
> The point of all this is my data validation is kept in one place so I
> can swap the interface as needed. The only commonality between all
> interfaces would be the use of an ActionForm and a List to hold
> returned validation 'exceptions'. And I have no problem with that. the
Form is just a POJO for
> all intents and purposes, as it should be. This leaves my interface to
be
> business logic stupid, but interface/UI logic smart.
>
> my $0.02.
>
>
> From: "David Thielen" <[EMAIL PROTECTED]>
> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> To: "Struts-Users" <[EMAIL PROTECTED]>
> Subject: validation philosophical question
> Date: Thu, 14 Aug 2003 10:31:27 -0600
>
> Hi;
>
> Everyone who hits my site has a high-speed connection. So I am
> thinking that it makes sense to do server side validation only as that
> provides a better method than the javascript pop-ups.
>
> And in this case, it seems to me that the logical place for all
> validation then is inside the ActionForm validate method.
>
> comments?
>
> thanks - dave
>
> _________________________________________________________________
> Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> _________________________________________________________________
> Protect your PC - get McAfee.com VirusScan Online
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- struts 1.1 + tomcat 4.1.27 + java 1.4.2 Linux 2.4.20 RH9
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
