struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laurie Harper <>
Subject Re: DynaActionForm and the 'pull' model
Date Thu, 19 May 2005 20:29:30 GMT
Adam Hardy wrote:
> Laurie,
> my chosen option would be to use your view objects as form objects, 
> where you modify the view object by adding string-typed getters and 
> setters for every property. 

I'm not really keen to 'pollute' the view objects with String-type 
derived properties just for the HTML presentation; the view objects are 
how any client (web app, web service, Swing GUI, etc) would interact 
with the application. This also implies having String-to-model 
conversion code scattered through the view objects...

> I don't really get what you mean in your (2).

This is what I decided to try first. I threw together a prototype last 
night, and it seams to work well. Basically, the idea is:

- extend the view API to include 'View.toMap(Map props)' and 'void 
View.fromMap(Map props)' on each view class

- you can then do view.fromMap(form.getMap()) and 
view.toMap(form.getMap()) to translate between views and form beans

- add a custom tag which takes a form bean and a view and loads the 
form's map from the view (I've implemented this so it can lookup the 
form bean from an enclosing <html:form/> tag, so you only have to pass 
in the view)

Now, my JSPs can do something like this:

<jsp:useBean id="view" class="MyViewBean"/>
... setup view (e.g. populate from db) ...
<x:loadForm view="${view}"/>

Now, the form bean associated with the enclosing form is populated from 
the view object. On subsequent page loads, I can skip the loadForm tag, 
and the form bean has the data from the previous submission.

I still need to do some more testing, but this seems to be working nicely.

> I think the parameter handling issue is hugely debatable. I've lost 
> count of the number of discussions I have had about it.

Yeah, lots of options here :-)

> Alot depends on where you get your view objects from. Are they the data 
> transfer object pattern?

Roughly, yes. There's a 'service layer' that interacts with the domain 
model (business objects). It returns view objects which are POJOs 
containing the state from the business objects but not the behaviour.

> Whatever, try to keep it as simple as possible.

Always good advice! The trick is remembering who to keep it simple for, 
me or the end user ;-)


> Adam
> On 18/05/05 20:45&nbsp;Laurie Harper wrote:
>> [Appologies for the long post; hopefully it'll spark some interesting
>> discussion though.]
>> Does anybody develop with Struts using a 'pull' model (where JSPs 'pull'
>> in the data they need, rather than having it 'pushed' to them by a
>> calling action)? I've been doing this successfully for some time with
>> applications that only use forms for capturing new data, no editting of
>> existing data. Now that I come to add the ability to update existing
>> data to an application, I've hit a limitation in my design. I'm hoping
>> others have encountered the same issue, or have suggestions for dealing
>> with it.
>> Here's the problem: I generally have a JSP for capturing new data, which
>> will use a DynaActionForm to manage the form inputs through multiple
>> edit-validate cycles until the form data is accepted and committed to
>> the database. For display of existing data, a different JSP is used
>> which 'pulls' the data in (using a custom tag or by instantiating a
>> bean). This JSP is fronted by a simple ActionForward. The page renders
>> the data as pulled from the database. For the sake of simplicity, assume
>> this 'pull' step puts a POJO bean into some scope (request usually);
>> call this the view object.
>> Now, if I want to be able to edit that data, the form needs to render
>> the data from the view object the first time it loads, but from the
>> ActionForm instance on subsequent loads (after validation fails). The
>> submit action, when it succeeds, then rebuilds the view object from the
>> form data and submits it to the service/domain layer via a 'store'
>> operation.
>> Note that there is no custom action to populate the form bean; form data
>> is pulled by the JSP page for editting just as for display. The reason
>> for this is that it should be possible to build new forms/pages without
>> modifying Java code. That's a basic requirement for this application.
>> So, the question is, how do I (a) populate the form bean from the JSP
>> and (b) determine when to do so? Some options I've considered:
>> 1) write a custom tag that looks up the form bean and view object in the
>> appropriate scope and uses BeanUtils.describe() or some other method to
>> fill out the form bean; this would probably require the view objects to
>> expose a describe() method returning a Map since view objects represent
>> structured data (a view object may have properties that are themselves
>> view objects)
>> 2) write a 'form manager' bean JSPs can use to say 'populate this form
>> bean with data from this view object'. The form bean manager then does
>> the work that is usually done in actions in the traditional 'push'
>> model. To avoid excessive coupling, a describe() method on the view
>> objects would be a good idea (otherwise the manager class would have to
>> know the view -> form bean mapping rules for every view object and form
>> in the system).
>> 3) always render the form using the view object and have the submit
>> action update the view object with the form data before validating. This
>> wont work since view objects have typed properties and I wouldn't be
>> able to 'round trip' invalid inputs (the same reason form beans usually
>> only use String properties).
>> 4) seperate create, edit and view operations into different JSPs. Appart
>> from the duplication of markup that introduces, it only helps for the
>> create (always use the form bean) and view (always use the view object)
>> cases; edit is still 'broken'.
>> I'm leaning toward the form manager (option 2) so a JSP might look like:
>> <jsp:useBean var="view" class="..."/>
>> <jsp:useBean var="mgr" class="...FormManager"/>
>> <jsp:setProperty name="mgr" property="form" value="${the form bean}"/>
>> <jsp:setProperty name="mgr" property="view" value="${view}"/>
>> The form manager would take an instance of DynaActionForm and update its
>> map of properties from the view. (I'm assuming the form bean is mutable
>> in this way!) I'd still need to know when to invoke the form manager I
>> suppose, but that's easier to solve with a request parameter or other
>> 'state' tracker.
>> Anyone got any better approaches?
>> L.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message