Argh!

Am I the only one who finds this a bit...odd?

The whole point of the validation framework is that it removes the validation from the code, and makes it a separate concern specified in an external xml file.

Now this xdoclet module puts the validation right back in the source, with the additional benefit of putting it all in a javadoc comment which cannot be validated by a compiler.

So, in all seriousness, what does this gain you over a doValidate method? Not to mention the fact that based on the sample you've provided, you lose i18n and different date formats (12-22-2002 would look very strange outside of the US). IMHO this is exactly the kind of misuse that the core xdoclet people (Aslak/Ara) have expressed a dislike for.

On Wednesday, July 23, 2003, at 12:35 AM, Erik Hatcher wrote:

Nice work, Brock!

Some comments below....

On Tuesday, July 22, 2003, at 06:28 PM, Brock Bulger wrote:
Here is an example of the tag usage:
 
/**
 * @xwork.field name="created"
 * @xwork.field-validator.required message="created is a required field."
 * @xwork.field-validator.date-range
 *      min="12-22-2002"
 *      max="12-25-2002"
 *      message="The date must be between 12-22-2002 and 12-25-2002."
 */
 private Date created;

Why do you need @xwork.field name="..."? Would you ever make it different from the actual field name?


I build the <strutsvalidationxml> subtask for XDoclet, and one of the principles I really was rigorous about was not repeating myself (DRY). Since one of XDoclet's primary goals is to avoid duplication, I cringe when I see duplication with XDoclet @tags. At least, in the case where the names match up, the name="..." attribute should be omitted and the default value be the field name itself, I think.

Why do you have it tagged on a private field? XWork is not seeing that field at all, is it? What I did on the Struts side of things was have the setters tagged since that is the entry point for data before it is validated. I'm not sure how this differs with how XWork validation works, so I might be off base here. But should we be tagging setters rather than private fields?

Since there are XDoclet committers here, I think its reasonable to keep this subtask in the XDoclet codebase - lots of other 3rd party stuff is already there, including some earlier WebWork subtasks.

Erik



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork




------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Reply via email to