Raible's Wiki: XdocletActionForms

At line 1 changed 1 line.

!!Should ''Xdoclet'' Generate ''Struts ActionForms''?

!!Should ''XDoclet'' Generate ''Struts ActionForms''?

At line 3 changed 1 line.

In Appfuse, you may notice that the ActionForms are autogenerated from the model's entity beans using @struts xdoclet tags. After trying every which way to wrap my application design around this approach, it finally became obvious to me that this is one case xdoclet over steps it's bounds. Read on to find out why...

In [AppFuse], you may notice that the ActionForms are autogenerated from the model's entity beans using __@struts__ [XDoclet] tags. After trying every which way to wrap my application design around this approach, it finally became obvious to me that this is one case XDoclet over steps it's bounds. Read on to find out why...

At line 5 changed 1 line.

As much as it just seems so tempting and beautiful and quick, I truly, truly believe that generating ActionForms dynamically with xdoclet is just not the right way to go. I believe that the relationship between a model's entity beans and the ActionForms is a forced association, one of those things that you want to believe so badly that you will do whatever you can to make it seem like an association, when really there is little similarity at all.

As tempting, beautiful and quick it may seem, I truly believe that generating ActionForms dynamically with XDoclet from custom tags in the model's entity beans is just not the right way to go. I believe that the relationship between these entity beans and the ActionForms is a forced association, one that you would like to believe so badly that you will convince yourself there is a direct tie when really there is little similarity at all.

At line 7 changed 2 lines.

Entities are almost exactly the same as ActionForms in many cases, but the exceptions are enough to prove they should not be parallel (and even Ted Husted thinks so, one example being

http://husted.com/struts/tips/005.html but I have also read his comments elsewhere on the subject). ActionForms should be flexible to suit the view, not necessarily to suit the model. In fact, it is only your manager class (business delegate) that should care how you designed your ActionForms, so that even the DAO cares only about the entity design. Here are several reasons why xdoclet should not be used to make ActionForms from entities.

Entities have virtually the same fields as ActionForms in many cases, but the exceptions are enough to prove they should not be parallel (and even [Ted Husted|http://husted.com/struts/tips/005.html] thinks so). ActionForms should be flexible to suit the view, not necessarily to suit the model. In fact, it is only your manager class (business delegate) that should care how you designed your ActionForms, so that even the DAO cares only about the entity design. Here are several reasons why XDoclet should ''__NOT__'' be used to make ActionForms from entity beans:

At line 14 changed 1 line.

* ''Validation'' ~ It is very, very wrong (I believe) to use validation tags on your entity bean. On one form the date might have a range limitation, on another form it might not, but still be the same entity. xdoclet validation tags should go on the ActionForm class (an impossibility if you are generating the class dynamically, unless of course you transfer over the tags, but then other issues arise). Again, messy, messy.

* ''Validation'' - It is very, very wrong (I believe) to use validation tags on your entity bean. On one form the date might have a range limitation, on another form it might not, but still be the same entity. xdoclet validation tags should go on the ActionForm class (an impossibility if you are generating the class dynamically, unless of course you transfer over the tags, but then other issues arise). Again, messy, messy.

At line 22 changed 1 line.

That is my 2 cents and it is hard to convince me otherwise at this point because of how much easier it has already been to work with struts forms, xdoclet and my persistence data by abandoning xdoclet. Plus, now my entity beans don't have struts tags in them, a very important separation of model and view. Oh, and if I move a field to a different table/entity bean, I don't have to go redesign my form necessrily, though I do have to modify my Manager, but that is okay, because both are part of the business, not the view. The view is still safe. While I am dying for someone to see the light, I can live with enjoying it alone for a while. Remember, you don't want to overdo things, and this is backing away from xdoclet where it is prudent to do so.

That is my $0.02 and it is hard to convince me otherwise at this point because of how much easier it has already been to work with struts forms, xdoclet and my persistence data by abandoning xdoclet. Plus, now my entity beans don't have struts tags in them, a very important separation of model and view. Oh, and if I move a field to a different table/entity bean, I don't have to go redesign my form necessrily, though I do have to modify my Manager, but that is okay, because both are part of the business, not the view. The view is still safe. While I am dying for someone to see the light, I can live with enjoying it alone for a while. Remember, you don't want to overdo things, and this is backing away from xdoclet where it is prudent to do so.

~ [mojavelinux]

Raible's Wiki

AppFuse

Other Applications

XdocletActionForms