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 Mon, 23 May 2005 18:20:13 GMT
Dakota Jack wrote:

> If you want to discuss this, I have a number of things to say.  If you

So I see on your other reply ;-)

> find that "argumentative", then I won't offer anything more.  Having

No, I'm happy to discuss; it's always worth hearing another person's 

> JSPs "fetch" data indeed is putting application logic in the JSPs. 
> This does not give you flexibility.  Quite the opposite, it ties your
> model and you view down by coupling them.  Rather than give you
> flexibility it hamstrings you.

That's somewhat true from a development perspective; there's a design 
constraint in effect here that you're missing, though (see below).

> This also is no easier than writing the code where it should be, in the model.

True, at development time. But it's a lot easier if you don't *have* the 
source code to the model or rest of the system. Consider a comercial 
product implemented on Struts and JSPs. You build the product and ship 
it to customers. You don't ship the source code -- that's proprietary -- 
but you do ship the JSPs and you want the customers to be able to 
locally customize the application.

This is where the pull approach provides a great deal of flexibility. 
There are a lot of things you might want your customers to be able to do 
by way of customization that are simply not possible using a push 


> On 5/22/05, Laurie Harper <> wrote:
>>There's no code in the JSPs, though you could make the argument that
>>having the JSPs fetch the data they need, through whatever means, is
>>putting application logic in the JSPs. And yes, this is generally not
>>reommended. In this case it's minimal and the trade off is the
>>flexibility it provides anyone writing or modifying the JSPs. It's the
>>best way to provide an easily cusomizable solution without needing to
>>provide Java source code.
>>Dakota Jack wrote:
>>>You are just coding on the JSP page, which for reasons that have been
>>>discussed to death is a bad idea.  If you like it, have at it.   But,
>>>generally speaking this is a very bad idea.
>>>On 5/19/05, Laurie Harper <> wrote:
>>>>Adam Hardy wrote:
>>>>>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 ;-)
>>>>>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
>>>>>>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
>>>>>>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,
>>>>>>will use a DynaActionForm to manage the form inputs through multiple
>>>>>>edit-validate cycles until the form data is accepted and committed
>>>>>>the database. For display of existing data, a different JSP is used
>>>>>>which 'pulls' the data in (using a custom tag or by instantiating
>>>>>>bean). This JSP is fronted by a simple ActionForward. The page renders
>>>>>>the data as pulled from the database. For the sake of simplicity,
>>>>>>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).
>>>>>>submit action, when it succeeds, then rebuilds the view object from
>>>>>>form data and submits it to the service/domain layer via a 'store'
>>>>>>Note that there is no custom action to populate the form bean; form
>>>>>>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
>>>>>>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
>>>>>>fill out the form bean; this would probably require the view objects
>>>>>>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
>>>>>>bean with data from this view object'. The form bean manager then
>>>>>>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
>>>>>>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.
>>>>>>wont work since view objects have typed properties and I wouldn't
>>>>>>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.
>>>>>>from the duplication of markup that introduces, it only helps for
>>>>>>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
>>>>>><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
>>>>>>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
>>>>>>suppose, but that's easier to solve with a request parameter or other
>>>>>>'state' tracker.
>>>>>>Anyone got any better approaches?
>>>>To unsubscribe, e-mail:
>>>>For additional commands, e-mail:
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:

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

View raw message