DO NOT REPLY [Bug 4856] New: - Make ActionForm an Interface

[bu...@apache.org]

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: struts-dev@jakarta.apache.org
        ReportedBy: larryw@vestek.com


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
larryw@vestek.com

BTW, struts is one of those truly useful tools --  thanks for writing it! : )

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>