Hmm... Hani does have a point here (first time for everything I suppose)... can't really think what advantage this has over Real Java Code. Anyone?
----- Original Message ----- From: "Hani Suleiman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 22, 2003 10:02 PM Subject: Re: [OS-webwork] xdoclet module 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 ------------------------------------------------------- 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
