struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dakota Jack <dakota.j...@gmail.com>
Subject Re: DynaActionForm and the 'pull' model
Date Mon, 23 May 2005 06:29:48 GMT
If you want to discuss this, I have a number of things to say.  If you
find that "argumentative", then I won't offer anything more.  Having
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.

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

On 5/22/05, Laurie Harper <laurie@holoweb.net> 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.
> 
> L.
> 
> 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 <laurie@holoweb.net> wrote:
> >
> >>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 ;-)
> >>
> >>L.
> >>
> >>
> >>>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: user-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

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


Mime
View raw message