DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4856>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4856 Make ActionForm an Interface Summary: Make ActionForm an Interface Product: Struts Version: Unknown Platform: All OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Standard Actions AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Short description: Since Java doesn't have multiple inheritance, having ActionForm as an abstract class is causing a proliferation of classes that have the nearly the same functionality and implementation. Long description: I'm working on a project involving EJBs and Struts -- The EJB tier is capable of serving up both the standard remote-interface Entity Beans as well as Serializable 'info' objects that represent the same data as an Entity Bean (a.k.a Value Objects). These 'info' objects are what the client tier uses as the basis of it's data model. My ActionForm subclasses are basically equivalent to my Serializable 'info' objects (SIOs), except the ActionForm subclasses all have String fields, where the SIOs have other types, like Integer and java.sql.Timestamp. They are both JavaBeans-like: they contain only matching getXxx and setXxx accessors. That is the problem, they are twice the coding and maintenance, lots of duplication. What I would like to do is have the EJBTier serve the SIOs, and the struts tier ActionForms would subclass these SIOs, and _implement_ ActionForm, like this: public class ProductForm extends ProductInfo implements ActionForm { private ActionFormObj actionFormDelegate; public String getProductId() { return String.valueOf( productId ); } public void setProductId(String val) { productId = Integer.parseInt( val ); } .... } --productId is an int declared in ProductInfo.java --ActionFormObj is a new struts object that implements ActionForm, it is the same implementation as the current 1.0 ActionForm. All the ActionForm methods in the proposed interface ActionForm could simply be routed to the ActionFormObj. This way, my ProductForm would only need to implement the data type conversion functionality, like above. All the fields that are strings would have the get/set methods inherited from my SIO class. This approach makes a lot of sense (IMO) if you are approaching a project from the perspective of database first, middle-tier second, and presentation third -- which is different than web first, database second, where you could drive requirements differently. You could still have a subclassable ActionForm: make ActionForm an interface, and make a BasicForm or BasicActionForm implement ActionForm which could then be subclassed like the current 1.0 ActionForm class. Or, you could: 1. call the new interface ActionFormIF 2. provide the ability to not to have to subclass ActionForm, but rather implement ActionFormIF 3. make ActionForm implement ActionFormIF, make all the internals use ActionFormIF; ActionForm would still be subclassable 4. add a perform method to Action that uses ActionFormIF, keep the one that uses ActionForm 5. make an ActionFormDelegate for those developers who chose to implement ActionFormIF and subclass their own data classes, rather than subclass ActionForm ...and not break any existing code (meaning for people that use struts) I'll write it if you want : ) Thanks, Larry [EMAIL PROTECTED] BTW, struts is one of those truly useful tools -- thanks for writing it! : ) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
