Argh!
Am I the only one who finds this a bit...odd?
Nope, not at all. In fact I struggle with the right balance with XDoclet myself. I use it *pragmatically*, not religiously.
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.
Totally understood. As is the design for EJB deployment descriptors and web deployment descriptors too.... but to write ejb-jar.xml and web.xml (listener definitions are the main item here) by hand is no fun and has the side-effect of being error prone and potentially out of sync with the actual code.
In reality (in my current project), validation is not something that changes once configured for a form and it does not need to be completely decoupled from the Java form that it corresponds to. It's a Struts project, but in the big picture of validation there is not much difference in how it works... there is a validation.xml file that declares stuff like XWork's validation XML file and the framework takes care of the dirty work.
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.
Not validated by a compiler, true, but certainly can be validated by XDoclet when run. If something is not right then it could complain.
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.
What does it gain you? Having validations in a config file outside the source gives you the ability to use validation at multiple tiers - the SAME validation - JavaScript in the browser, web-tier with WebWork, and then even lower in business tier if desired. I have used the Struts JavaScript validation piece without having to write anything, just simply drop in a taglib into the page and the same validation is done client-side. That is sweet!
I consider myself a "core XDoclet person" too and certainly push back on XDoclet abuse myself. In Struts, generating validation.xml makes a lot of sense since you are forced to have a form bean (unless you're insane and use DynaActionForm's) - provided validation does not need to change on a per-deployment basis (which would be rare, I'd think).
In WebWork, I'm still withholding judgment whether XDoclet makes sense or not. Since you can push your business objects out from an Action, I certainly agree that tagging validation on business objects themselves is suspect.
I think ultimately this is not a black and white area. There are pros/cons to the use of XDoclet, as well as for not using it at all. Each project is different and if tagging and generating is not beneficial or a time-saver than don't do it. If it helps then do it. :)
Erik
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
