DO NOT REPLY [Bug 21541] New: - LImitation in struts model component

[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=21541>.
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=21541

LImitation in struts model component

           Summary: LImitation in struts model component
           Product: Struts
           Version: 1.1 Final
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Controller
        AssignedTo: struts-dev@jakarta.apache.org
        ReportedBy: sgabriel@brainfuse.com


Struts model component requires the developer to rewrite a new bean for each 
form of the application that they create.
 The developer then has to read all the data from the form bean and insert to 
the business logic components that can then be verified and persisted. 
There is this extra step that always has to be done when setting up forms. 
Additionally most of the webforms they are persisted in one or more business 
logic objects. On occasions the number of fields are not even constant and so 
is the number of beans. Take for a example a registration form that allows the 
user to enter more than one address work, home and more. Each one of these 
addresses correspond to an Address business object which has to be created, 
initialized and verified and then added to the Customer business object. 

With struts there is always this extra step of building a corresponding 
adapter object. The adapter is always a flat object not hirerachal like 
objects in normal life. From this object all the sub objects has to be filled 
again into the actual business objects which might seem like something that 
struts can handle in its model component framework. On a higher level struts 
moved developers from using object.setMethod(request.getParameter) into 
Object.setMethod ( formBean.getMethod). I am not denying all the values of the 
struts model, but I am just saying that struts can do that on its own using 
configuration files that the user has to do anyway. 


With a different design struts could have a mapping directly to business 
objects where business logic is generally validated. and by the time the 
controller method is called all objects are setup in memory already, at this 
point all the developer has to do is call persistence method or call any other 
method required by the business objects. 

The XML configuration can have multiple <bean> tags within the form bean tag. 
Within each bean tag there would be a <source> tag that tells struts how to 
initialize or acquire this bean object which could be something as simple as 
creating a new instance, looking up an object within a specified scope or 
calling a getter method on another bean object within a specified scope e.g. 
customer.getStreetAddress. It will be the responsibility of the getter method 
not to return a null object.
Within each bean tag there could be a mapping element(s) which matches form 
fields to methods either generically but using get/set(ParamName) or by 
defining matcher element that can use regular express to match the form field 
to the bean(s) method. for example
<matcher fieldExp="address-address1-\d" value="customer.getAddresses
{1}.setAddress1(value)/>
This is optional for complicated forms only.

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org