struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <>
Subject Re: DynaActionForm and the 'pull' model
Date Wed, 18 May 2005 22:01:37 GMT

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 don't really get what you mean in your (2).

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

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

Whatever, try to keep it as simple as possible.


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