You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Laurie Harper <la...@holoweb.net> on 2005/05/18 21:45:38 UTC
DynaActionForm and the 'pull' model
[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
Re: DynaActionForm and the 'pull' model
Posted by Laurie Harper <la...@holoweb.net>.
Adam Hardy wrote:
> On 19/05/05 21:29 Laurie Harper wrote:
>
>> 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.
>
>
> You skip the whole tag? Using JSTL or something in the JSP? How do you
> tell? Can you do that inside the loadForm tag to keep the JSP cleaner?
I haven't settled on a mechanism for deciding yet; I'm leaning towards
just having a query parameter reload=true or something, then using
notPresent to wrap the loadForm tag.
> Surely though you need some items of data just for display (which wont
> be resubmitted with the form because you didn't put them in form fields)
> and you can also use the view object to check whether you need to save
> (if nothing changed)?
Yes, quite likely, and using the pull model I can always get the data I
need at the point where I need it. All this is just a mechanism on top
of that to enable form data to be round-tripped cleanly.
> BTW how does your viewbean behave? Does it call the back end when it is
> instantiated, or just when it decides it needs the data?
I have a service layer which implements the business transactions the
system supports. It's responsible for using a DAO to load domain data
and transfer it into view objects. So basically, the view objects / DTOs
are the data encapsulation mechanism for interacting with the service
layer.
From the presentation layer's perspective, the view objects are how it
invokes data retrival operations on the service layer. So in my JSP I
say 'use bean User, set view to loginId' and the bean takes care of
calling the UserService.lookupUser(userId) method and populating itself.
Or something like that, the design is still emerging as I prototype :)
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
On 19/05/05 21:29 Laurie Harper wrote:
> 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.
You skip the whole tag? Using JSTL or something in the JSP? How do you
tell? Can you do that inside the loadForm tag to keep the JSP cleaner?
Surely though you need some items of data just for display (which wont
be resubmitted with the form because you didn't put them in form fields)
and you can also use the view object to check whether you need to save
(if nothing changed)?
BTW how does your viewbean behave? Does it call the back end when it is
instantiated, or just when it decides it needs the data?
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Dakota Jack <da...@gmail.com>.
You will also find that JSTL, etc., are not really made for coding on
the page and that the efficiency loss is huge.
On 5/28/05, Eddie Bush <ea...@swbell.net> wrote:
> I actually agree with Jack on this one. Ideally, you should architect your
> application into layers:
>
> +------------------+
> | Application |
> +------------------+
> | Business Objects |
> +------------------+
> | DAO |
> +------------------+
> | Persistence |
> +------------------+
>
> The idea being that you can code the bottom three independent of the top
> one - as well as unit and system test them independently. The
> application-specific layer then does nothing but coordinate the conversation
> between the application and your business rules. In a Struts application,
> generally, the action classes are the place this coordination takes place.
>
> Doing things this way buys you a lot that is hard for me to convey in words.
> I'd strongly recommend using this approach though as it'll be far easier on
> you down the road.
>
> Regards,
>
> Eddie Bush
>
> ----- Original Message -----
> From: "Laurie Harper" <la...@holoweb.net>
> To: <us...@struts.apache.org>
> Sent: Sunday, May 22, 2005 7:36 PM
> Subject: Re: DynaActionForm and the 'pull' model
>
>
> > 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.
>
>
>
> ---
> avast! Antivirus: Outbound message clean.
> Virus Database (VPS): 0521-4, 05/27/2005
> Tested on: 5/28/2005 1:22:00 PM
> avast! - copyright (c) 2000-2004 ALWIL Software.
> http://www.avast.com
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: DynaActionForm and the 'pull' model
Posted by Eddie Bush <ea...@swbell.net>.
I actually agree with Jack on this one. Ideally, you should architect your
application into layers:
+------------------+
| Application |
+------------------+
| Business Objects |
+------------------+
| DAO |
+------------------+
| Persistence |
+------------------+
The idea being that you can code the bottom three independent of the top
one - as well as unit and system test them independently. The
application-specific layer then does nothing but coordinate the conversation
between the application and your business rules. In a Struts application,
generally, the action classes are the place this coordination takes place.
Doing things this way buys you a lot that is hard for me to convey in words.
I'd strongly recommend using this approach though as it'll be far easier on
you down the road.
Regards,
Eddie Bush
----- Original Message -----
From: "Laurie Harper" <la...@holoweb.net>
To: <us...@struts.apache.org>
Sent: Sunday, May 22, 2005 7:36 PM
Subject: Re: DynaActionForm and the 'pull' model
> 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.
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0521-4, 05/27/2005
Tested on: 5/28/2005 1:22:00 PM
avast! - copyright (c) 2000-2004 ALWIL Software.
http://www.avast.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Dakota Jack <da...@gmail.com>.
Okay, Michael. If this is what you like, good luck. I am stopping
the conversation from my side if it is staying at this level.
On 5/23/05, Michael Jouravlev <jm...@gmail.com> wrote:
> > > 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.
>
> So what? These two will always be related unless you use simple
> meaningless DTOs with no relation to business objects. I personally do
> not use this type of DTO, I prefer to use real business objects in the
> view. I don't care that it ties view to the model. But at least I get
> readable, understandable code and I get business rules. Oh, right, I
> use business objects for input too, in this example they are used
> solely for output... But Laurie said, that it is not a real business
> object, it is just a "view object", so view is actually not tied that
> tight to the model.
>
> > 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.
>
> You do realize, that JSP _is_ a part of app source code, do you? And
> the more you put into JSP, the more this supposedly dumb JSP page will
> look like "real code"? If you ship without source code, you'd rather
> precompile the JSPs.
>
> Now, to your problem. I will try to think right while I am typing.
> First of all, I haven't actually used dynaforms, so no advices here.
> Now, you want your input to go to action form? Why? Apparently,
> because you want Struts to parse request data, and to perform
> automatic validation. OK. So you need to associate form bean with
> every incoming request, but you do not want to redefine form beans,
> hence dynaform.
>
> Struts uses getters and setters to put values into the form (at least
> if it is not a dynamic form), so you can use getters and setters to
> direct where the data goes... I am not sure how do you do this with
> dynabean, but with regular bean you would have your getter pulling
> data from your view object, and the setter storing data in the form
> field. Then, after validation, you would type-convert and copy values
> from form fields to your view object.
>
> Or... you can still pull data from your view object and display values
> using bean:write. But the tags themselves will have "property"
> pointing to the form bean. I am not sure how this will work, but if
> you were able to print values from view object, and submit them to the
> form bean, then you'd just copy them to view object, and _then_
> validate them. Then, if needed, you would redisplay data again from
> the view object, which contains updated data (possibly incorrect, but
> who cares, this view object is a _copy_ of a real object anyway,
> right?). In this case you do not need getters in the form bean.
> Because there are no getters, this "pull from view object, submit to
> action form" might work. I have not really tried it.
>
> Michael.
>
> ---------------------------------------------------------------------
> 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
Re: DynaActionForm and the 'pull' model
Posted by Laurie Harper <la...@holoweb.net>.
Michael Jouravlev wrote:
> You do realize, that JSP _is_ a part of app source code, do you? And
Err, well, yes... ;-)
> the more you put into JSP, the more this supposedly dumb JSP page will
> look like "real code"? If you ship without source code, you'd rather
> precompile the JSPs.
That would make the task of customizing the application somewhat harder!
:-) The point is that the customer can edit the JSPs but I don't want
them to have to edit and recompile action classes in order to achieve
the customizations they need. So yes, they get some 'source code' (the
JSPs) but not the rest.
I should also perhaps clarify that I do use the normal action
proceessing model for handling inputs; the pull model is used mainly for
simple view operations. The problem at hand is how to translate between
the view objects used for exposing data to the JSP and the form beans
used when submitting it for update.
The view object can't be used for storing form inputs if validation
fails, since they are typed data structures. Hence, on first load, the
page obtains a view to display; on subsequent re-loads due to validation
failing, it needs to use the form bean instead of the view object. Once
the form is submitted successfully, I handle transfering the content of
the form bean into the view and, from there, to the domain model all
server-side. No problem there.
L.
>
> Now, to your problem. I will try to think right while I am typing.
> First of all, I haven't actually used dynaforms, so no advices here.
> Now, you want your input to go to action form? Why? Apparently,
> because you want Struts to parse request data, and to perform
> automatic validation. OK. So you need to associate form bean with
> every incoming request, but you do not want to redefine form beans,
> hence dynaform.
>
> Struts uses getters and setters to put values into the form (at least
> if it is not a dynamic form), so you can use getters and setters to
> direct where the data goes... I am not sure how do you do this with
> dynabean, but with regular bean you would have your getter pulling
> data from your view object, and the setter storing data in the form
> field. Then, after validation, you would type-convert and copy values
> from form fields to your view object.
>
> Or... you can still pull data from your view object and display values
> using bean:write. But the tags themselves will have "property"
> pointing to the form bean. I am not sure how this will work, but if
> you were able to print values from view object, and submit them to the
> form bean, then you'd just copy them to view object, and _then_
> validate them. Then, if needed, you would redisplay data again from
> the view object, which contains updated data (possibly incorrect, but
> who cares, this view object is a _copy_ of a real object anyway,
> right?). In this case you do not need getters in the form bean.
> Because there are no getters, this "pull from view object, submit to
> action form" might work. I have not really tried it.
>
> Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Michael Jouravlev <jm...@gmail.com>.
> > 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.
So what? These two will always be related unless you use simple
meaningless DTOs with no relation to business objects. I personally do
not use this type of DTO, I prefer to use real business objects in the
view. I don't care that it ties view to the model. But at least I get
readable, understandable code and I get business rules. Oh, right, I
use business objects for input too, in this example they are used
solely for output... But Laurie said, that it is not a real business
object, it is just a "view object", so view is actually not tied that
tight to the model.
> 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.
You do realize, that JSP _is_ a part of app source code, do you? And
the more you put into JSP, the more this supposedly dumb JSP page will
look like "real code"? If you ship without source code, you'd rather
precompile the JSPs.
Now, to your problem. I will try to think right while I am typing.
First of all, I haven't actually used dynaforms, so no advices here.
Now, you want your input to go to action form? Why? Apparently,
because you want Struts to parse request data, and to perform
automatic validation. OK. So you need to associate form bean with
every incoming request, but you do not want to redefine form beans,
hence dynaform.
Struts uses getters and setters to put values into the form (at least
if it is not a dynamic form), so you can use getters and setters to
direct where the data goes... I am not sure how do you do this with
dynabean, but with regular bean you would have your getter pulling
data from your view object, and the setter storing data in the form
field. Then, after validation, you would type-convert and copy values
from form fields to your view object.
Or... you can still pull data from your view object and display values
using bean:write. But the tags themselves will have "property"
pointing to the form bean. I am not sure how this will work, but if
you were able to print values from view object, and submit them to the
form bean, then you'd just copy them to view object, and _then_
validate them. Then, if needed, you would redisplay data again from
the view object, which contains updated data (possibly incorrect, but
who cares, this view object is a _copy_ of a real object anyway,
right?). In this case you do not need getters in the form bean.
Because there are no getters, this "pull from view object, submit to
action form" might work. I have not really tried it.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Laurie Harper <la...@holoweb.net>.
That's an interesting approach, though I think a much more complicated
solution than I need. My objective isn't to allow clients to script
actions or otherwise modify their behaviour, but to make that
unnecessary. This approach would certainly allow one to provide much
more power if that were needed though.
L.
Frank W. Zammetti wrote:
> Rather than pollute the view (if one chooses to perceive it that way...
> I'm staying away from that debate!), why not introduce some sort of
> scripting engine into the mix? I'm not really sure precisely where
> because I don't know your project, but I say this based on your comment:
>
> "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."
>
> Think of something like Microsoft Excel... you don't have access to the
> source code obviously, but it exposes are rather rich object model that
> you can manipulate through scripting. This lets you customize the app in
> essence in just about any way you want without needing the source. It
> also is arguably better architecturally than allowing someone to alter the
> dialog resources of the app (not a perfect analogy I realize, but
> hopefully close enough to get the point across).
>
> There is the scripted Actions project specifically for Struts, there's
> Jelly that might be applicable, the BSF, etc.
>
> Something along those lines is almost tailor-made for the "the client
> needs to modify our product in some way" situation.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Rather than pollute the view (if one chooses to perceive it that way...
I'm staying away from that debate!), why not introduce some sort of
scripting engine into the mix? I'm not really sure precisely where
because I don't know your project, but I say this based on your comment:
"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."
Think of something like Microsoft Excel... you don't have access to the
source code obviously, but it exposes are rather rich object model that
you can manipulate through scripting. This lets you customize the app in
essence in just about any way you want without needing the source. It
also is arguably better architecturally than allowing someone to alter the
dialog resources of the app (not a perfect analogy I realize, but
hopefully close enough to get the point across).
There is the scripted Actions project specifically for Struts, there's
Jelly that might be applicable, the BSF, etc.
Something along those lines is almost tailor-made for the "the client
needs to modify our product in some way" situation.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Mon, May 23, 2005 2:20 pm, Laurie Harper said:
> 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
> perspective.
>
>> 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
> methodology.
>
> L.
>
>>
>> On 5/22/05, Laurie Harper <la...@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 <la...@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 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
>>>
>>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: DynaActionForm and the 'pull' model
Posted by Laurie Harper <la...@holoweb.net>.
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
perspective.
> 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
methodology.
L.
>
> On 5/22/05, Laurie Harper <la...@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 <la...@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 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
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Dakota Jack <da...@gmail.com>.
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 <la...@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 <la...@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 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
Re: DynaActionForm and the 'pull' model
Posted by Laurie Harper <la...@holoweb.net>.
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 <la...@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 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
Re: DynaActionForm and the 'pull' model
Posted by Dakota Jack <da...@gmail.com>.
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 <la...@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 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
>
>
--
"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
Re: DynaActionForm and the 'pull' model
Posted by Laurie Harper <la...@holoweb.net>.
Adam Hardy wrote:
>> 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...
>
> OK, valid point, but you then go on to say that you have a method on
> your view object to provide all the string-typed properties in a map to
> your form bean or get them from your form bean.
>
> I think what you are doing is mixing and matching the struts-paradigm
> (front servlet pattern) with what JSF wants to do. Which is actually a
> good idea because (a) I thinks struts needs something more and (b) I
> don't like the JSF point-and-click .NET wanna-be approach.
That's exactly right; the traditional Struts paradigm is 'push', where
there are actions which feed data into the request before the JSP is
called. What I'm working with is 'pull' where the JSPs aquire the data
they need themselves. Struts becomes the mediator for page flow and
operations which modify state on the server. Pure view operations have
minimal dependance on Struts.
> By the way this isn't my only reply - I wanted to split the subject - I
> am posting again with questions about your design.
>
> From a design perspective, there's something niggling me about your
> view objects. The view whether it is a GUI or HTTP is basically a
> framework or layer that should provide an API for stuff like
> string-to-type conversion. So I agree you should not pollute the view
> objects with such code. It's just semantics I guess - they're not really
> 'view objects' - they're DTOs. I guess you put the data together from
> various data object in the back end, right?
That's right, yes. The methods for translating to/from Maps of Strings
is a convenience for the presentation layer on top. The advantage of
making the view objects / DTOs responsible for this is it reduces
coupling. The presentation layer can be less intimately entwined with
the view layer ;-)
> What I am aiming for is a DynaActionForm that I can configure in xml but
> including type info. There would also be a validation mechanism - do you
> want a validation error if the type cast fails? etc.
>
> <form-bean name="libraryForm"
> type="org.apache.struts.validator.AdamsDynaValidatorForm">
> <form-property name="sectionId"
> type="java.lang.String"
> cast="java.lang.Integer"
> validate="true"
> />
> </form-bean>
>
> You could populate it with BeanUtils or with your toMap() method.
>
> I guess this is only one step removed from what you've got anyway. It's
> just encapsulated within the formbean and view layer framework.
Yeah, that would be a good abstraction. But it does mean that the view /
DTO objects and the Struts configuration have to be kept closely in
sync. I think some sort of typed form bean would be a good general
solution, though; I suspect a lot of people would find this approach
appealing -- I'd probably have adopted it in my case if it had existed
already!
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Laurie Harper <la...@holoweb.net>.
Adam Hardy wrote:
>> 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...
>
> OK, valid point, but you then go on to say that you have a method on
> your view object to provide all the string-typed properties in a map to
> your form bean or get them from your form bean.
>
> I think what you are doing is mixing and matching the struts-paradigm
> (front servlet pattern) with what JSF wants to do. Which is actually a
> good idea because (a) I thinks struts needs something more and (b) I
> don't like the JSF point-and-click .NET wanna-be approach.
That's exactly right; the traditional Struts paradigm is 'push', where
there are actions which feed data into the request before the JSP is
called. What I'm working with is 'pull' where the JSPs aquire the data
they need themselves. Struts becomes the mediator for page flow and
operations which modify state on the server. Pure view operations have
minimal dependance on Struts.
> By the way this isn't my only reply - I wanted to split the subject - I
> am posting again with questions about your design.
>
> From a design perspective, there's something niggling me about your
> view objects. The view whether it is a GUI or HTTP is basically a
> framework or layer that should provide an API for stuff like
> string-to-type conversion. So I agree you should not pollute the view
> objects with such code. It's just semantics I guess - they're not really
> 'view objects' - they're DTOs. I guess you put the data together from
> various data object in the back end, right?
That's right, yes. The methods for translating to/from Maps of Strings
is a convenience for the presentation layer on top. The advantage of
making the view objects / DTOs responsible for this is it reduces
coupling. The presentation layer can be less intimately entwined with
the view layer ;-)
> What I am aiming for is a DynaActionForm that I can configure in xml but
> including type info. There would also be a validation mechanism - do you
> want a validation error if the type cast fails? etc.
>
> <form-bean name="libraryForm"
> type="org.apache.struts.validator.AdamsDynaValidatorForm">
> <form-property name="sectionId"
> type="java.lang.String"
> cast="java.lang.Integer"
> validate="true"
> />
> </form-bean>
>
> You could populate it with BeanUtils or with your toMap() method.
>
> I guess this is only one step removed from what you've got anyway. It's
> just encapsulated within the formbean and view layer framework.
Yeah, that would be a good abstraction. But it does mean that the view /
DTO objects and the Struts configuration have to be kept closely in
sync. I think some sort of typed form bean would be a good general
solution, though; I suspect a lot of people would find this approach
appealing -- I'd probably have adopted it in my case if it had existed
already!
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
On 19/05/05 21:29 Laurie Harper 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...
OK, valid point, but you then go on to say that you have a method on
your view object to provide all the string-typed properties in a map to
your form bean or get them from your form bean.
I think what you are doing is mixing and matching the struts-paradigm
(front servlet pattern) with what JSF wants to do. Which is actually a
good idea because (a) I thinks struts needs something more and (b) I
don't like the JSF point-and-click .NET wanna-be approach.
By the way this isn't my only reply - I wanted to split the subject - I
am posting again with questions about your design.
From a design perspective, there's something niggling me about your
view objects. The view whether it is a GUI or HTTP is basically a
framework or layer that should provide an API for stuff like
string-to-type conversion. So I agree you should not pollute the view
objects with such code. It's just semantics I guess - they're not really
'view objects' - they're DTOs. I guess you put the data together from
various data object in the back end, right?
What I am aiming for is a DynaActionForm that I can configure in xml but
including type info. There would also be a validation mechanism - do you
want a validation error if the type cast fails? etc.
<form-bean name="libraryForm"
type="org.apache.struts.validator.AdamsDynaValidatorForm">
<form-property name="sectionId"
type="java.lang.String"
cast="java.lang.Integer"
validate="true"
/>
</form-bean>
You could populate it with BeanUtils or with your toMap() method.
I guess this is only one step removed from what you've got anyway. It's
just encapsulated within the formbean and view layer framework.
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Laurie Harper <la...@holoweb.net>.
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 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
Re: DynaActionForm and the 'pull' model
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
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 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.
Adam
On 18/05/05 20:45 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
Re: DynaActionForm and the 'pull' model
Posted by Dakota Jack <da...@gmail.com>.
Sorry, Laurie, but if you are going to define your own meanings for
"request" and so on, then I just don't have time to learn how you are
speaking, even if what you said was enticing. I am not saying you are
wrong, just that I would prefer to use terms in a standard way to
avoid having to learn idiosyncratic usage. The bottom line, however,
is that I am not open at this stage in my career to suggestions that
putting code into JSP pages is a good idea without a bang up and clear
argument for that option. I don't see it here.
On 5/24/05, Laurie Harper <la...@holoweb.net> wrote:
> >>
> >>Sure, but I'm not talking about request objects. A request to
> >>http://host/myapp/something.jsp (with no query parameters) contains no
> >>request data, but the JSP still has to display information. What I'm
> >>taling about is how that information is retrieved from the backend.
--
"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
Re: DynaActionForm and the 'pull' model
Posted by Laurie Harper <la...@holoweb.net>.
It doesn't help to say 'your terms do not have the meaning you've
defined them to have for purposes of this discuession' and conclude that
the following arguments are invalide. Re-read the requirement I stated
below. Your concluding comments do not in any way address it.
L.
Dakota Jack wrote:
> On 5/23/05, Laurie Harper <la...@holoweb.net> wrote:
>
>>Dakota Jack wrote:
>>
>>>You cannot talk about request objects and ignore the client. The
>>>requests come from the client.
>>
>>Sure, but I'm not talking about request objects. A request to
>>http://host/myapp/something.jsp (with no query parameters) contains no
>>request data, but the JSP still has to display information. What I'm
>>taling about is how that information is retrieved from the backend.
>
>
> A string containing a protocol (http) a URL (host) and a number of
> other identification matters (myapp, something.jsp) whether having
> query parameters or not is not a request. All sorts of data goes with
> a request on all occasions which enable the communications in for
> example, http to take place.
>
>
>>Absolutely, which is why it's important when using pull to keep it
>>simple and make sure data retrieval is as declarative as possible. I'm
>>certainly not advocating that JSPs should be making JDBC calls or anything.
>
>
> I repeat, again, you are not using the terms "pull", or "push", or
> "request" the way they are used. Your use is idiosyncratic. There is
> not hing declarative about your approach either. This is not what
> "declarative" means in this context.
>
>
>>As I said in my previous post, you need to understand the design
>>constraints. No approach solves every solution, no design rule is
>>inviolate. I'm using a pull model to solve a very specific requirement:
>>that the data displayed on a JSP page should be able to be changed /from
>>the JSP page/, without access to the application source code.
>
>
> This is not, again, a "pull/push" issue. Pull and push are
> relationships between client and server. Your relationship is between
> the view and the model.
>
> This also is not related to "design constraints" or "design rules".
> This is just coding on the JSP page and is really not a good idea. It
> is such a bad idea that whole technologies are invented to avoid it.
> If you are running a "mom and pop" show, this is not important. In
> that case, not much would be important. But, in the "craft" of
> programming, which admittedly is not rocket science, it is important.
>
>
>
>>I can see why it looks, at first glance, like I'm doing something badly
>>wrong but, in the light of that requirement, I'm not aware of another
>>approach that's workable. Feel free to suggest alternatives if you have
>>them :-)
>
>
> Just use some framework, like Struts. Write your actions and your
> model to take are of this business and feed the data to the
> appropriate scopes and objects.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Dave Newton <ne...@pingsite.com>.
Dakota Jack wrote:
>If these are the issues, then you must be speaking some language with Ms. Harper
>that I don't know.
>
>
Of that I have little doubt.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: DynaActionForm and the 'pull' model
Posted by Michael Oliver <ol...@sourceonenet.com>.
For the most part I agree with DJ. I am a firm believer in the
separation of concerns and the avoidance of business logic in the
'view'.
BUT the event metaphor clouds the issue and as the thin clients become
rich clients, the need to apply some business logic to enable 'richness'
become the exception that proves the rule. This is probably more
germane to DJ's response than to the original question. But since it is
relatively rare that I agree with the majority of what DJ says...I
thought I owed it to him.
Michael Oliver
CTO
Alarius Systems LLC
6800 E. Lake Mead Blvd, #1096
Las Vegas, NV 89156
Phone:(702)643-7425
Fax:(702)974-0341
*Note new email changed from oliverm@matrix-media.com
-----Original Message-----
From: Dakota Jack [mailto:dakota.jack@gmail.com]
Sent: Saturday, May 28, 2005 11:58 AM
To: Struts Users Mailing List; craigmcc@apache.org
Subject: Re: DynaActionForm and the 'pull' model
The View Helper pattern creates presentation *content* which requires
processing of dynamic business data. The forces are that the business
data assimillation requirements are nontrivial, embedding business
logic in the view would promote a copy-and-paste type of reuse, you
want a clean separation of labor between the software developers and
the web production team, and one view is commonly used to respond to a
particular business request.
The solution is to have the view contain only formatting code,
delegating its processing responsibilities to helper classes,
implemented as Java Beans or custom tags. The helpers also store the
view's intermediate data model and serve as business data adapters.
In other words, these sorts of solutions have absolutely nothing to do
with the View Helper pattern. They are, in fact, antithetical to that
pattern.
On 5/26/05, Craig McClanahan <cr...@gmail.com> wrote:
> On 5/24/05, Laurie Harper <la...@holoweb.net> wrote:
> > Nope, Dave nailed it. Re-read the requirement I described. The point
is
> > to avoid using actions to load the data and pass it to the view. If
you
> > re-read my description of what I mean by 'push' vs. 'pull' rather
than
> > simply saying the terms mean something different it might help.
>
> Laurie,
>
> (Sorry for the late response -- just getting back from vacation).
>
> You might want to take a look at how Shale approaches your "pull"
requirement.
>
> http://wiki.apache.org/struts/StrutsShale/
>
> Being JSF based, Shale encourages you to associate a single bean with
> each JSP page, where the bean can have more than one behavior (versus
> a Struts 1.x action where the only behavior is to process the submit).
> In particular, Shale supports a prerender() method that can be used
> to pull the data that this page "knows" it needs from the model -- and
> it sits right next to the logic (in a separate method) that processes
> the subsequent submit. In Struts 1.x terms, prerender() is where
> you'd do the things you currently do in a setup action, while the
> normal event handling method (called an "action" in JSF parlance, but
> it's a method instead of a class) does the follow-up updates to the
> model.
>
> In Struts 1.x, you see this same idea directly implemented in Tiles,
> via the Controller interface. It's also a dominant idea in ASP.Net,
> Tapestry, and Spring MVC -- and it's sorta immortalized in the J2EE
> design patterns lexicon as the View Helper pattern.
>
> I'd be interested to hear if this is close to what you had in mind, or
> if it was something else again.
>
> Craig McClanahan
>
>
>
>
> >
> > I think I'll drop the topic now, before this degrades into a flame
fest.
> >
> > L.
> >
> > Dakota Jack wrote:
> >
> > > I believe the point was nothing like this at all, Dave. Don't
know
> > > why you thought it was. Seems like you just thought this stuff up
> > > separate to me. However, certainly I don't think that the issue
> > > whether or not you are writing a CMS is relevant to the issues
> > > discussed. I also have no idea why you went off on the XML stuff.
> > > This is simply an issue of where work on the model should be.
Your
> > > discussion, so far as I can tell, is about something entirely
> > > different and I have no idea where you got these issues. If these
are
> > > the issues, then you must be speaking some language with Ms.
Harper
> > > that I don't know.
> > >
> > > On 5/23/05, Dave Newton <ne...@pingsite.com> wrote:
> > >
> > >>Dakota Jack wrote:
> > >>
> > >>
> > >>>Just use some framework, like Struts. Write your actions and
your
> > >>>model to take are of this business and feed the data to the
> > >>>appropriate scopes and objects.
> > >>>
> > >>>
> > >>
> > >>I believe the point was that this isn't an option.
> > >
> > >
> >
> >
> >
---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Dakota Jack <da...@gmail.com>.
The View Helper pattern creates presentation *content* which requires
processing of dynamic business data. The forces are that the business
data assimillation requirements are nontrivial, embedding business
logic in the view would promote a copy-and-paste type of reuse, you
want a clean separation of labor between the software developers and
the web production team, and one view is commonly used to respond to a
particular business request.
The solution is to have the view contain only formatting code,
delegating its processing responsibilities to helper classes,
implemented as Java Beans or custom tags. The helpers also store the
view's intermediate data model and serve as business data adapters.
In other words, these sorts of solutions have absolutely nothing to do
with the View Helper pattern. They are, in fact, antithetical to that
pattern.
On 5/26/05, Craig McClanahan <cr...@gmail.com> wrote:
> On 5/24/05, Laurie Harper <la...@holoweb.net> wrote:
> > Nope, Dave nailed it. Re-read the requirement I described. The point is
> > to avoid using actions to load the data and pass it to the view. If you
> > re-read my description of what I mean by 'push' vs. 'pull' rather than
> > simply saying the terms mean something different it might help.
>
> Laurie,
>
> (Sorry for the late response -- just getting back from vacation).
>
> You might want to take a look at how Shale approaches your "pull" requirement.
>
> http://wiki.apache.org/struts/StrutsShale/
>
> Being JSF based, Shale encourages you to associate a single bean with
> each JSP page, where the bean can have more than one behavior (versus
> a Struts 1.x action where the only behavior is to process the submit).
> In particular, Shale supports a prerender() method that can be used
> to pull the data that this page "knows" it needs from the model -- and
> it sits right next to the logic (in a separate method) that processes
> the subsequent submit. In Struts 1.x terms, prerender() is where
> you'd do the things you currently do in a setup action, while the
> normal event handling method (called an "action" in JSF parlance, but
> it's a method instead of a class) does the follow-up updates to the
> model.
>
> In Struts 1.x, you see this same idea directly implemented in Tiles,
> via the Controller interface. It's also a dominant idea in ASP.Net,
> Tapestry, and Spring MVC -- and it's sorta immortalized in the J2EE
> design patterns lexicon as the View Helper pattern.
>
> I'd be interested to hear if this is close to what you had in mind, or
> if it was something else again.
>
> Craig McClanahan
>
>
>
>
> >
> > I think I'll drop the topic now, before this degrades into a flame fest.
> >
> > L.
> >
> > Dakota Jack wrote:
> >
> > > I believe the point was nothing like this at all, Dave. Don't know
> > > why you thought it was. Seems like you just thought this stuff up
> > > separate to me. However, certainly I don't think that the issue
> > > whether or not you are writing a CMS is relevant to the issues
> > > discussed. I also have no idea why you went off on the XML stuff.
> > > This is simply an issue of where work on the model should be. Your
> > > discussion, so far as I can tell, is about something entirely
> > > different and I have no idea where you got these issues. If these are
> > > the issues, then you must be speaking some language with Ms. Harper
> > > that I don't know.
> > >
> > > On 5/23/05, Dave Newton <ne...@pingsite.com> wrote:
> > >
> > >>Dakota Jack wrote:
> > >>
> > >>
> > >>>Just use some framework, like Struts. Write your actions and your
> > >>>model to take are of this business and feed the data to the
> > >>>appropriate scopes and objects.
> > >>>
> > >>>
> > >>
> > >>I believe the point was that this isn't an option.
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: DynaActionForm and the 'pull' model
Posted by Dakota Jack <da...@gmail.com>.
This is a long thread, so it might be worth repeating that Laurie
wants her (human) clients to be able to write Java code on the JSP
page. She seems to call this "data pulling".
On 5/29/05, Ted Husted <te...@gmail.com> wrote:
> On 5/28/05, Laurie Harper <la...@holoweb.net> wrote:
> > Thanks for the reference Craig; but unless I'm mis-reading you, that
> > still leaves me with data lookup 'hard coded' in Java classes. My goal
> > is to be able to change a page's data requirements without
> > recompilation.
>
> If it would be OK to edit an XML configuration in concert with the
> page, then the Chain of Responsiblity might be useful. Each page can
> have a "view" command, which can be a chain of commands. When the data
> requirements of the page changes, the chain's configuration can be
> updated to add or subtract commands. Each command can be responsible
> for generating the content of a given control. The action just runs
> the chain and exposes the context to the page. If the chain changes,
> the context changes, but the Java code remains the same.
>
> Between iBATIS and Chain, we are able to make very significant changes
> to the content of a page, without touching the actual source code,
> just the XML configuration.
>
> -Ted.
>
> ---------------------------------------------------------------------
> 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
Re: DynaActionForm and the 'pull' model
Posted by Ted Husted <te...@gmail.com>.
On 5/28/05, Laurie Harper <la...@holoweb.net> wrote:
> Thanks for the reference Craig; but unless I'm mis-reading you, that
> still leaves me with data lookup 'hard coded' in Java classes. My goal
> is to be able to change a page's data requirements without
> recompilation.
If it would be OK to edit an XML configuration in concert with the
page, then the Chain of Responsiblity might be useful. Each page can
have a "view" command, which can be a chain of commands. When the data
requirements of the page changes, the chain's configuration can be
updated to add or subtract commands. Each command can be responsible
for generating the content of a given control. The action just runs
the chain and exposes the context to the page. If the chain changes,
the context changes, but the Java code remains the same.
Between iBATIS and Chain, we are able to make very significant changes
to the content of a page, without touching the actual source code,
just the XML configuration.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Laurie Harper <la...@holoweb.net>.
Thanks for the reference Craig; but unless I'm mis-reading you, that
still leaves me with data lookup 'hard coded' in Java classes. My goal
is to be able to change a page's data requirements without
recompilation. I'll take a look at Shale though and see if it has
anything to help in that context.
L.
Craig McClanahan wrote:
> Laurie,
>
> (Sorry for the late response -- just getting back from vacation).
>
> You might want to take a look at how Shale approaches your "pull" requirement.
>
> http://wiki.apache.org/struts/StrutsShale/
>
> Being JSF based, Shale encourages you to associate a single bean with
> each JSP page, where the bean can have more than one behavior (versus
> a Struts 1.x action where the only behavior is to process the submit).
> In particular, Shale supports a prerender() method that can be used
> to pull the data that this page "knows" it needs from the model -- and
> it sits right next to the logic (in a separate method) that processes
> the subsequent submit. In Struts 1.x terms, prerender() is where
> you'd do the things you currently do in a setup action, while the
> normal event handling method (called an "action" in JSF parlance, but
> it's a method instead of a class) does the follow-up updates to the
> model.
>
> In Struts 1.x, you see this same idea directly implemented in Tiles,
> via the Controller interface. It's also a dominant idea in ASP.Net,
> Tapestry, and Spring MVC -- and it's sorta immortalized in the J2EE
> design patterns lexicon as the View Helper pattern.
>
> I'd be interested to hear if this is close to what you had in mind, or
> if it was something else again.
>
> Craig McClanahan
>
>
>
>
>
>>I think I'll drop the topic now, before this degrades into a flame fest.
>>
>>L.
>>
>>Dakota Jack wrote:
>>
>>
>>>I believe the point was nothing like this at all, Dave. Don't know
>>>why you thought it was. Seems like you just thought this stuff up
>>>separate to me. However, certainly I don't think that the issue
>>>whether or not you are writing a CMS is relevant to the issues
>>>discussed. I also have no idea why you went off on the XML stuff.
>>>This is simply an issue of where work on the model should be. Your
>>>discussion, so far as I can tell, is about something entirely
>>>different and I have no idea where you got these issues. If these are
>>>the issues, then you must be speaking some language with Ms. Harper
>>>that I don't know.
>>>
>>>On 5/23/05, Dave Newton <ne...@pingsite.com> wrote:
>>>
>>>
>>>>Dakota Jack wrote:
>>>>
>>>>
>>>>
>>>>>Just use some framework, like Struts. Write your actions and your
>>>>>model to take are of this business and feed the data to the
>>>>>appropriate scopes and objects.
>>>>>
>>>>>
>>>>
>>>>I believe the point was that this isn't an option.
>>>
>>>
>>
>>---------------------------------------------------------------------
>>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
Re: DynaActionForm and the 'pull' model
Posted by Craig McClanahan <cr...@gmail.com>.
On 5/24/05, Laurie Harper <la...@holoweb.net> wrote:
> Nope, Dave nailed it. Re-read the requirement I described. The point is
> to avoid using actions to load the data and pass it to the view. If you
> re-read my description of what I mean by 'push' vs. 'pull' rather than
> simply saying the terms mean something different it might help.
Laurie,
(Sorry for the late response -- just getting back from vacation).
You might want to take a look at how Shale approaches your "pull" requirement.
http://wiki.apache.org/struts/StrutsShale/
Being JSF based, Shale encourages you to associate a single bean with
each JSP page, where the bean can have more than one behavior (versus
a Struts 1.x action where the only behavior is to process the submit).
In particular, Shale supports a prerender() method that can be used
to pull the data that this page "knows" it needs from the model -- and
it sits right next to the logic (in a separate method) that processes
the subsequent submit. In Struts 1.x terms, prerender() is where
you'd do the things you currently do in a setup action, while the
normal event handling method (called an "action" in JSF parlance, but
it's a method instead of a class) does the follow-up updates to the
model.
In Struts 1.x, you see this same idea directly implemented in Tiles,
via the Controller interface. It's also a dominant idea in ASP.Net,
Tapestry, and Spring MVC -- and it's sorta immortalized in the J2EE
design patterns lexicon as the View Helper pattern.
I'd be interested to hear if this is close to what you had in mind, or
if it was something else again.
Craig McClanahan
>
> I think I'll drop the topic now, before this degrades into a flame fest.
>
> L.
>
> Dakota Jack wrote:
>
> > I believe the point was nothing like this at all, Dave. Don't know
> > why you thought it was. Seems like you just thought this stuff up
> > separate to me. However, certainly I don't think that the issue
> > whether or not you are writing a CMS is relevant to the issues
> > discussed. I also have no idea why you went off on the XML stuff.
> > This is simply an issue of where work on the model should be. Your
> > discussion, so far as I can tell, is about something entirely
> > different and I have no idea where you got these issues. If these are
> > the issues, then you must be speaking some language with Ms. Harper
> > that I don't know.
> >
> > On 5/23/05, Dave Newton <ne...@pingsite.com> wrote:
> >
> >>Dakota Jack wrote:
> >>
> >>
> >>>Just use some framework, like Struts. Write your actions and your
> >>>model to take are of this business and feed the data to the
> >>>appropriate scopes and objects.
> >>>
> >>>
> >>
> >>I believe the point was that this isn't an option.
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: DynaActionForm and the 'pull' model
Posted by Dave Newton <ne...@pingsite.com>.
Dakota Jack wrote:
>[...] and am not interested in Dave's little flame bit.
>
>
You were interested enough to assume that what I said was flame bait and
respond passive-aggresively, when really all I said was that it was
obvious that we weren't talking about the same thing. Now for a _better_
example of flame bait check out your original response to my post where
you went on at length about how I had no idea what the issue was and
that I must have been conversing with Laurie in a different language.
*sigh*
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Dakota Jack <da...@gmail.com>.
Okay, Laurie. I did miss that you were somehow setting it up so that
clients could actually modify your JSP pages directly. That surprises
me and I missed it. Good for Dave, he caught that. I still don't see
where you said that, but if that is the project, then I certainly have
no more to say and am not interested in Dave's little flame bit.
Sorry for missing your point.
On 5/24/05, Laurie Harper <la...@holoweb.net> wrote:
> Nope, Dave nailed it. Re-read the requirement I described. The point is
> to avoid using actions to load the data and pass it to the view. If you
> re-read my description of what I mean by 'push' vs. 'pull' rather than
> simply saying the terms mean something different it might help.
>
> I think I'll drop the topic now, before this degrades into a flame fest.
>
> L.
>
> Dakota Jack wrote:
>
> > I believe the point was nothing like this at all, Dave. Don't know
> > why you thought it was. Seems like you just thought this stuff up
> > separate to me. However, certainly I don't think that the issue
> > whether or not you are writing a CMS is relevant to the issues
> > discussed. I also have no idea why you went off on the XML stuff.
> > This is simply an issue of where work on the model should be. Your
> > discussion, so far as I can tell, is about something entirely
> > different and I have no idea where you got these issues. If these are
> > the issues, then you must be speaking some language with Ms. Harper
> > that I don't know.
> >
> > On 5/23/05, Dave Newton <ne...@pingsite.com> wrote:
> >
> >>Dakota Jack wrote:
> >>
> >>
> >>>Just use some framework, like Struts. Write your actions and your
> >>>model to take are of this business and feed the data to the
> >>>appropriate scopes and objects.
> >>>
> >>>
> >>
> >>I believe the point was that this isn't an option.
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: DynaActionForm and the 'pull' model
Posted by Dave Newton <ne...@pingsite.com>.
Laurie Harper wrote:
> Nope, Dave nailed it. Re-read the requirement I described. The point
> is to avoid using actions to load the data and pass it to the view. If
> you re-read my description of what I mean by 'push' vs. 'pull' rather
> than simply saying the terms mean something different it might help.
I think somebody mentioned this before, but I'll reiterate: you might
want to think about something like Jython server pages or wrangling
something Jython-esque into a custom tag body, etc. which would give you
a full-on language that doesn't require compilation.
If you provide reasonable hooks into your system from objects dropped in
the app/session/request this might be a convenient way to support the
functionality you want.
That said, I'd feel like I had a "safer" system if things were handled
via XML configs etc. rather than code, which can be risky. It depends on
who your target audience is (sort of the "languages for the masses" vs.
"languages for smart people" argument) and how much you trust 'em :)
I was able to accomplish a LOT in a short amount of time by doing a fair
amount of work in Jython and making Jython code loadable from a DB: we
didn't have access to the production system, so making any quick
"tweaks" was out of the question. Since it was the developers that were
playing with the most dynamic code bits we could expose a lot of
functionality without fear of somebody (purposefully or accidentally)
doing the Wrong Thing. Your situation might be different, but it's an idea.
> I think I'll drop the topic now, before this degrades into a flame fest.
Wuss!!! ;)
*lol*
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Laurie Harper <la...@holoweb.net>.
Nope, Dave nailed it. Re-read the requirement I described. The point is
to avoid using actions to load the data and pass it to the view. If you
re-read my description of what I mean by 'push' vs. 'pull' rather than
simply saying the terms mean something different it might help.
I think I'll drop the topic now, before this degrades into a flame fest.
L.
Dakota Jack wrote:
> I believe the point was nothing like this at all, Dave. Don't know
> why you thought it was. Seems like you just thought this stuff up
> separate to me. However, certainly I don't think that the issue
> whether or not you are writing a CMS is relevant to the issues
> discussed. I also have no idea why you went off on the XML stuff.
> This is simply an issue of where work on the model should be. Your
> discussion, so far as I can tell, is about something entirely
> different and I have no idea where you got these issues. If these are
> the issues, then you must be speaking some language with Ms. Harper
> that I don't know.
>
> On 5/23/05, Dave Newton <ne...@pingsite.com> wrote:
>
>>Dakota Jack wrote:
>>
>>
>>>Just use some framework, like Struts. Write your actions and your
>>>model to take are of this business and feed the data to the
>>>appropriate scopes and objects.
>>>
>>>
>>
>>I believe the point was that this isn't an option.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Dakota Jack <da...@gmail.com>.
I believe the point was nothing like this at all, Dave. Don't know
why you thought it was. Seems like you just thought this stuff up
separate to me. However, certainly I don't think that the issue
whether or not you are writing a CMS is relevant to the issues
discussed. I also have no idea why you went off on the XML stuff.
This is simply an issue of where work on the model should be. Your
discussion, so far as I can tell, is about something entirely
different and I have no idea where you got these issues. If these are
the issues, then you must be speaking some language with Ms. Harper
that I don't know.
On 5/23/05, Dave Newton <ne...@pingsite.com> wrote:
> Dakota Jack wrote:
>
> >Just use some framework, like Struts. Write your actions and your
> >model to take are of this business and feed the data to the
> >appropriate scopes and objects.
> >
> >
> I believe the point was that this isn't an option.
--
"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
Re: DynaActionForm and the 'pull' model
Posted by Dave Newton <ne...@pingsite.com>.
Dakota Jack wrote:
>Just use some framework, like Struts. Write your actions and your
>model to take are of this business and feed the data to the
>appropriate scopes and objects.
>
>
I believe the point was that this isn't an option. It seems to me, in
this case, that the client wants more control over the application, but
for various reasons won't be writing Actions, etc.
Therefore another way "in" to the system needs to be provided, whatever
vernacular anybody wants to use.
To me it looks like a place where a different delivery mechanism, like
XML, and subsequent transformation might be more appropriate: more
service-oriented rather than page-oriented.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Dakota Jack <da...@gmail.com>.
On 5/23/05, Laurie Harper <la...@holoweb.net> wrote:
> Dakota Jack wrote:
> > You cannot talk about request objects and ignore the client. The
> > requests come from the client.
>
> Sure, but I'm not talking about request objects. A request to
> http://host/myapp/something.jsp (with no query parameters) contains no
> request data, but the JSP still has to display information. What I'm
> taling about is how that information is retrieved from the backend.
A string containing a protocol (http) a URL (host) and a number of
other identification matters (myapp, something.jsp) whether having
query parameters or not is not a request. All sorts of data goes with
a request on all occasions which enable the communications in for
example, http to take place.
> Absolutely, which is why it's important when using pull to keep it
> simple and make sure data retrieval is as declarative as possible. I'm
> certainly not advocating that JSPs should be making JDBC calls or anything.
I repeat, again, you are not using the terms "pull", or "push", or
"request" the way they are used. Your use is idiosyncratic. There is
not hing declarative about your approach either. This is not what
"declarative" means in this context.
> As I said in my previous post, you need to understand the design
> constraints. No approach solves every solution, no design rule is
> inviolate. I'm using a pull model to solve a very specific requirement:
> that the data displayed on a JSP page should be able to be changed /from
> the JSP page/, without access to the application source code.
This is not, again, a "pull/push" issue. Pull and push are
relationships between client and server. Your relationship is between
the view and the model.
This also is not related to "design constraints" or "design rules".
This is just coding on the JSP page and is really not a good idea. It
is such a bad idea that whole technologies are invented to avoid it.
If you are running a "mom and pop" show, this is not important. In
that case, not much would be important. But, in the "craft" of
programming, which admittedly is not rocket science, it is important.
>
> I can see why it looks, at first glance, like I'm doing something badly
> wrong but, in the light of that requirement, I'm not aware of another
> approach that's workable. Feel free to suggest alternatives if you have
> them :-)
Just use some framework, like Struts. Write your actions and your
model to take are of this business and feed the data to the
appropriate scopes and objects.
--
"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
Re: DynaActionForm and the 'pull' model
Posted by Dakota Jack <da...@gmail.com>.
Normally, Camilo, when you have a question you start your own thread.
On 5/23/05, Camilo Quevedo <c-...@uniandes.edu.co> wrote:
> Hi, I'm trying to create a struts application, but it seams that when i
> ask for a user input (html:form) it doesn't,t recognize the special
> characters. How can I configure my application so that it accepts
> special character??
>
> So far I've done this:
>
> i my jsp I put <%@ page contentType="text/html;charset=UTF-8"
> language="java" %>
>
> and in my action I used, request.setCharacterEncoding("UTF-8");
> and it still doesn't work.
>
> What can I do??
>
> Camilo
>
> ---------------------------------------------------------------------
> 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
Re: DynaActionForm and the 'pull' model
Posted by Camilo Quevedo <c-...@uniandes.edu.co>.
Hi, I'm trying to create a struts application, but it seams that when i
ask for a user input (html:form) it doesn't,t recognize the special
characters. How can I configure my application so that it accepts
special character??
So far I've done this:
i my jsp I put <%@ page contentType="text/html;charset=UTF-8"
language="java" %>
and in my action I used, request.setCharacterEncoding("UTF-8");
and it still doesn't work.
What can I do??
Camilo
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Laurie Harper <la...@holoweb.net>.
Dakota Jack wrote:
> You cannot talk about request objects and ignore the client. The
> requests come from the client.
Sure, but I'm not talking about request objects. A request to
http://host/myapp/something.jsp (with no query parameters) contains no
request data, but the JSP still has to display information. What I'm
taling about is how that information is retrieved from the backend.
> Any data coming to a JSP comes in the same way. This is not pull and
> this is not push. The data comes from some class existing in some
> scope: page, request, session, application. You are not doing
> anything new. You are just doing the old stuff badly, I believe. I
> only say that to be helpful as I can be and not to belittle you or
> anything like that.
>
> Your cases has the JSP more than requesting the data. Your case has
> the JSP in charge of getting the data. That is very different. Any
> data coming to a JSP must be "requested", i.e. gotten from some call
> from the JSP page. Your pages does more, viz. instantiates the
> objects, etc. which provide the data on the JSP page.
>
> Again, your idea that way is flexible is not true. You are less able
> to "customize" with your approach because you have all sorts of
> disparate code tied to each other. If you have a variable on a JSP
> page be a logical reference to data, then the physical source of that
> data becomes irrelevant. You, however, make direct references rather
> than logical references and tie down your code completely.
JSPs access data through page/request/session scoped variables, just
like yours do. With a push methodology, a JSP may assume that there will
be a request scoped variable 'user' which references a bean of type
UserView. It renders the page by making reference to the properties of
this bean through the 'user' variable.
The only difference with a pull methodology is that, somewhere in the
JSP, there is a <jsp:useBean class="UserView"/>. The rest of the JSP is
written exactly as it would have been using a pull methodology. There's
no 'disparate code' and the references to data are no more or less
direct than when using push.
> The coupling is the problem. Coupling leads to fragile, rigid, code
> which is expensive to maintain.
Absolutely, which is why it's important when using pull to keep it
simple and make sure data retrieval is as declarative as possible. I'm
certainly not advocating that JSPs should be making JDBC calls or anything.
> I hope this is helpful, and realize that I am just stating my opinion.
> I don't think you are at all right, but certainly am willing to
> listen to what you have to say.
As I said in my previous post, you need to understand the design
constraints. No approach solves every solution, no design rule is
inviolate. I'm using a pull model to solve a very specific requirement:
that the data displayed on a JSP page should be able to be changed /from
the JSP page/, without access to the application source code.
I can see why it looks, at first glance, like I'm doing something badly
wrong but, in the light of that requirement, I'm not aware of another
approach that's workable. Feel free to suggest alternatives if you have
them :-)
L.
>
> On 5/22/05, Laurie Harper <la...@holoweb.net> wrote:
>
>>You're bluring the distinction between client-side behaviour and
>>server-side behaviour a little there. Ignore the client side for the
>>moment; I'm talking only about how the application works on the server.
>>
>>The issue is about how the JSP gets access to the data it needs to
>>display. Normally, as you say, there would be an action or some other
>>server-side component which executes before the JSP and places data into
>>some scope which the JSP then retrieves. That's what I'm refering to as
>>a 'push' model, in that there is some component pushing data out to the JSP.
>>
>>In my case, I want the JSP to get access to the data by explicitly
>>requesting it -- i.e. 'pulling in' the data it needs. As I noted in my
>>other reply to you, this could be seen as breaking the MVC paradigm by
>>putting application logic in the JSP. There's some truth in that.
>>
>>The reason I do it is quite simple. By having the JSPs aquire the data
>>they need in this way, it is much easier to customize the application
>>after it is delivered. Page flow can be changed, additional information
>>can be shown on an existing page, and so, all without modifying Java
>>code. That means I can deliver a highly customizable product. It's a
>>trade-off: I bend MVC encapsulation, but gain a significant benefit.
>>
>>So, 'pull', in the context of this discussion, just refers to how the
>>JSP gets acces to the data it needs. In my implementation, the JSPs
>>instantiate beans which represent a view of the data they need. The
>>beans then do the work of interacting with the backend (via a service
>>layer). So the data access is really still in the controller part of the
>>application, it's just being triggered by the JSPs rather than by a
>>Struts action. In a way, you can think of it as using the JSPs to
>>declaratively describe what data they will use rather than having to
>>have an action or other component know in advance.
>>
>>L.
>>
>>Dakota Jack wrote:
>>
>>
>>>A few thoughts:
>>>
>>>(1) The push/pull dichotomy really does not apply to what you are
>>>talking about. That relationship is between the client and the server
>>>and has more to do with the nature of the protocol, viz. HTTP, being
>>>employed in a browser context.
>>>
>>>(2) Likewise, some of the other things you say seem to not track the
>>>semantics of the actual problem space. For example, JSPs never
>>>"capture data" but are used to create dynamic HTML in the response.
>>>The data always comes from the request object which only indirectly is
>>>related to the prior JSP page and the form elements available on that
>>>page. We could always put together a request object without any JSP
>>>at all and scoot it off to the server. Hackers, of course, do just
>>>that.
>>>
>>>(3) A JSP page "fronted" by a simple ActionForward cannot be populated
>>>unless you have something put the populating bean in some scope.
>>>Presumably that activity has to somehow be explained. Why you do not
>>>what to use an ActionForm or this is not clear. I do many things, of
>>>course, without the ActionForm participating, but the Action or the
>>>ActionForm must be doing something. A simple ActionForward cannot
>>>give you a bean with the data you need. Something is wrong with this
>>>description. I would guess that you have some Action put the bean
>>>into scope. This has nothing to do with "pull" as that term is
>>>normally used in the "push/pull" discussions outside Dr. Dolittle's
>>>push-pull llama.
>>>
>>>(4) When you say there is no "custom" action to populate the bean but
>>>that it is "pulled" from the page, I can only think that you mean you
>>>have the code that should be in the model on the JSP page. If so,
>>>this is not "pull" and is not a good idea.
>>>
>>>Is that right? If not, then I don't know where the so-called "pull
>>>data" is coming from.
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>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
Re: DynaActionForm and the 'pull' model
Posted by Dakota Jack <da...@gmail.com>.
You cannot talk about request objects and ignore the client. The
requests come from the client.
Any data coming to a JSP comes in the same way. This is not pull and
this is not push. The data comes from some class existing in some
scope: page, request, session, application. You are not doing
anything new. You are just doing the old stuff badly, I believe. I
only say that to be helpful as I can be and not to belittle you or
anything like that.
Your cases has the JSP more than requesting the data. Your case has
the JSP in charge of getting the data. That is very different. Any
data coming to a JSP must be "requested", i.e. gotten from some call
from the JSP page. Your pages does more, viz. instantiates the
objects, etc. which provide the data on the JSP page.
Again, your idea that way is flexible is not true. You are less able
to "customize" with your approach because you have all sorts of
disparate code tied to each other. If you have a variable on a JSP
page be a logical reference to data, then the physical source of that
data becomes irrelevant. You, however, make direct references rather
than logical references and tie down your code completely.
The coupling is the problem. Coupling leads to fragile, rigid, code
which is expensive to maintain.
I hope this is helpful, and realize that I am just stating my opinion.
I don't think you are at all right, but certainly am willing to
listen to what you have to say.
On 5/22/05, Laurie Harper <la...@holoweb.net> wrote:
> You're bluring the distinction between client-side behaviour and
> server-side behaviour a little there. Ignore the client side for the
> moment; I'm talking only about how the application works on the server.
>
> The issue is about how the JSP gets access to the data it needs to
> display. Normally, as you say, there would be an action or some other
> server-side component which executes before the JSP and places data into
> some scope which the JSP then retrieves. That's what I'm refering to as
> a 'push' model, in that there is some component pushing data out to the JSP.
>
> In my case, I want the JSP to get access to the data by explicitly
> requesting it -- i.e. 'pulling in' the data it needs. As I noted in my
> other reply to you, this could be seen as breaking the MVC paradigm by
> putting application logic in the JSP. There's some truth in that.
>
> The reason I do it is quite simple. By having the JSPs aquire the data
> they need in this way, it is much easier to customize the application
> after it is delivered. Page flow can be changed, additional information
> can be shown on an existing page, and so, all without modifying Java
> code. That means I can deliver a highly customizable product. It's a
> trade-off: I bend MVC encapsulation, but gain a significant benefit.
>
> So, 'pull', in the context of this discussion, just refers to how the
> JSP gets acces to the data it needs. In my implementation, the JSPs
> instantiate beans which represent a view of the data they need. The
> beans then do the work of interacting with the backend (via a service
> layer). So the data access is really still in the controller part of the
> application, it's just being triggered by the JSPs rather than by a
> Struts action. In a way, you can think of it as using the JSPs to
> declaratively describe what data they will use rather than having to
> have an action or other component know in advance.
>
> L.
>
> Dakota Jack wrote:
>
> > A few thoughts:
> >
> > (1) The push/pull dichotomy really does not apply to what you are
> > talking about. That relationship is between the client and the server
> > and has more to do with the nature of the protocol, viz. HTTP, being
> > employed in a browser context.
> >
> > (2) Likewise, some of the other things you say seem to not track the
> > semantics of the actual problem space. For example, JSPs never
> > "capture data" but are used to create dynamic HTML in the response.
> > The data always comes from the request object which only indirectly is
> > related to the prior JSP page and the form elements available on that
> > page. We could always put together a request object without any JSP
> > at all and scoot it off to the server. Hackers, of course, do just
> > that.
> >
> > (3) A JSP page "fronted" by a simple ActionForward cannot be populated
> > unless you have something put the populating bean in some scope.
> > Presumably that activity has to somehow be explained. Why you do not
> > what to use an ActionForm or this is not clear. I do many things, of
> > course, without the ActionForm participating, but the Action or the
> > ActionForm must be doing something. A simple ActionForward cannot
> > give you a bean with the data you need. Something is wrong with this
> > description. I would guess that you have some Action put the bean
> > into scope. This has nothing to do with "pull" as that term is
> > normally used in the "push/pull" discussions outside Dr. Dolittle's
> > push-pull llama.
> >
> > (4) When you say there is no "custom" action to populate the bean but
> > that it is "pulled" from the page, I can only think that you mean you
> > have the code that should be in the model on the JSP page. If so,
> > this is not "pull" and is not a good idea.
> >
> > Is that right? If not, then I don't know where the so-called "pull
> > data" is coming from.
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: DynaActionForm and the 'pull' model
Posted by Laurie Harper <la...@holoweb.net>.
You're bluring the distinction between client-side behaviour and
server-side behaviour a little there. Ignore the client side for the
moment; I'm talking only about how the application works on the server.
The issue is about how the JSP gets access to the data it needs to
display. Normally, as you say, there would be an action or some other
server-side component which executes before the JSP and places data into
some scope which the JSP then retrieves. That's what I'm refering to as
a 'push' model, in that there is some component pushing data out to the JSP.
In my case, I want the JSP to get access to the data by explicitly
requesting it -- i.e. 'pulling in' the data it needs. As I noted in my
other reply to you, this could be seen as breaking the MVC paradigm by
putting application logic in the JSP. There's some truth in that.
The reason I do it is quite simple. By having the JSPs aquire the data
they need in this way, it is much easier to customize the application
after it is delivered. Page flow can be changed, additional information
can be shown on an existing page, and so, all without modifying Java
code. That means I can deliver a highly customizable product. It's a
trade-off: I bend MVC encapsulation, but gain a significant benefit.
So, 'pull', in the context of this discussion, just refers to how the
JSP gets acces to the data it needs. In my implementation, the JSPs
instantiate beans which represent a view of the data they need. The
beans then do the work of interacting with the backend (via a service
layer). So the data access is really still in the controller part of the
application, it's just being triggered by the JSPs rather than by a
Struts action. In a way, you can think of it as using the JSPs to
declaratively describe what data they will use rather than having to
have an action or other component know in advance.
L.
Dakota Jack wrote:
> A few thoughts:
>
> (1) The push/pull dichotomy really does not apply to what you are
> talking about. That relationship is between the client and the server
> and has more to do with the nature of the protocol, viz. HTTP, being
> employed in a browser context.
>
> (2) Likewise, some of the other things you say seem to not track the
> semantics of the actual problem space. For example, JSPs never
> "capture data" but are used to create dynamic HTML in the response.
> The data always comes from the request object which only indirectly is
> related to the prior JSP page and the form elements available on that
> page. We could always put together a request object without any JSP
> at all and scoot it off to the server. Hackers, of course, do just
> that.
>
> (3) A JSP page "fronted" by a simple ActionForward cannot be populated
> unless you have something put the populating bean in some scope.
> Presumably that activity has to somehow be explained. Why you do not
> what to use an ActionForm or this is not clear. I do many things, of
> course, without the ActionForm participating, but the Action or the
> ActionForm must be doing something. A simple ActionForward cannot
> give you a bean with the data you need. Something is wrong with this
> description. I would guess that you have some Action put the bean
> into scope. This has nothing to do with "pull" as that term is
> normally used in the "push/pull" discussions outside Dr. Dolittle's
> push-pull llama.
>
> (4) When you say there is no "custom" action to populate the bean but
> that it is "pulled" from the page, I can only think that you mean you
> have the code that should be in the model on the JSP page. If so,
> this is not "pull" and is not a good idea.
>
> Is that right? If not, then I don't know where the so-called "pull
> data" is coming from.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DynaActionForm and the 'pull' model
Posted by Dakota Jack <da...@gmail.com>.
A few thoughts:
(1) The push/pull dichotomy really does not apply to what you are
talking about. That relationship is between the client and the server
and has more to do with the nature of the protocol, viz. HTTP, being
employed in a browser context.
(2) Likewise, some of the other things you say seem to not track the
semantics of the actual problem space. For example, JSPs never
"capture data" but are used to create dynamic HTML in the response.
The data always comes from the request object which only indirectly is
related to the prior JSP page and the form elements available on that
page. We could always put together a request object without any JSP
at all and scoot it off to the server. Hackers, of course, do just
that.
(3) A JSP page "fronted" by a simple ActionForward cannot be populated
unless you have something put the populating bean in some scope.
Presumably that activity has to somehow be explained. Why you do not
what to use an ActionForm or this is not clear. I do many things, of
course, without the ActionForm participating, but the Action or the
ActionForm must be doing something. A simple ActionForward cannot
give you a bean with the data you need. Something is wrong with this
description. I would guess that you have some Action put the bean
into scope. This has nothing to do with "pull" as that term is
normally used in the "push/pull" discussions outside Dr. Dolittle's
push-pull llama.
(4) When you say there is no "custom" action to populate the bean but
that it is "pulled" from the page, I can only think that you mean you
have the code that should be in the model on the JSP page. If so,
this is not "pull" and is not a good idea.
Is that right? If not, then I don't know where the so-called "pull
data" is coming from.
--
"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