I'm not arguing against annotations, only saying that per-method valdidations are supported.
One workaround would be to let the validation.xml include another validation.xml. I haven't tried, but this might already be possible using XML entities. But, again, the annotation support would also be a good thing. -Ted. On 1/31/07, David H. DeWolf <[EMAIL PROTECTED]> wrote:
Yes, but that requires seperate validations config per method - even if they are identical. Take a dumb example. . .suppose you have an action with simple methods: load create update delete Perhaps you have the same validation on create and update, but do not want them to execute on load and delete. If I want per-method validation, I would have to create two distinct validation.xml files (CrudAction-create-validation.xml & CrudAction-update-validation.xml) as opposed to only one which is "activated" for the specific action methods I want validation to occur on. Are there any ways around the duplication problem that I'm not aware of? David Ted Husted wrote: > Per-method validations are supported, using the convention > > * ActionClass-actionMethod-validation.xml > > This approach doesn't work with "dynamic method invocation" though > (the WW ! notation), because of the way DMI is implemented. Per method > validation does work with wildcards, though. > > -Ted. > > On 1/29/07, David Rupp <[EMAIL PROTECTED]> wrote: >> Hi, all. >> >> I've submitted a patch to the XWork project (issue XW-470) that >> enables per-method validations when using annotations. This is, IMO, >> an improvement over the current behavior, with which all validations >> are attached to the class, and *all* fire when *any* method is >> executed. Since validation annotations, by definition, *must* be >> defined on a specific method, it seems more reasonable to expect that >> the validations defined on a given method would fire when - and only >> when - that method is executed. >> >> I have a specific need for this behavior on my current project, but >> I'd rather not be in the position of maintaining a forked version of >> XWork just for it. I'd love it if some of the folks from this group >> could take a look at my patch (included on the issue) and let me know >> how it can be improved, assuming I'm not the only one who would like >> to see this behavior implemented. >> >> Regards, >> David > > --------------------------------------------------------------------- > 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]
-- HTH, Ted. * http://www.husted.com/struts/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
