You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Dakota Jack <da...@gmail.com> on 2005/03/17 20:04:23 UTC
Multiple ActionForms per ActionMapping
I have put forward a very basis description of what I take to be a
compelling case for multiple ActionForms for Actions. I encourage any
of you to hammer what I say there, add to the facts, straighten out
the logic, etc., because for me this is an very important point. I am
surprised if it is not an important point for all of us. Surprise me,
if it is not.
I am ready to see that I am missing something, because Ted thinks
otherwise and he usually is the epitome of good common sense in
coding. I don't see it here and am open to being taught something
new.
Jack
--
"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: Multiple ActionForms per ActionMapping
Posted by Joe Germuska <Jo...@Germuska.com>.
>*I guess my question is what scenario are you guys mentioning that
>is common for the cause of this concern? I'm guessing it is step 2.C
>above? With the preponderance of possible struts questions that come
>along this certainly is not 'that' common. I don't see that many
>applications where every page is a form and each form's population
>of fields is that intricately tied to what was submitted on the
>previous form. (Exception of course is wizard based applications -
>like steps to filling out online taxes, which in that case, I think
>one ActionForm across requests is the cleanest approach).
>
>I'm not trying to be a pain, but I'm sure I'm not the only one that
>is slightly confused by the problem statement that you are posing on
>the wiki page.
You are correct that I'm trying to deal with step 2.C (copied below).
It's true that it isn't necessarily the most common problem people
face, but it is one of the more common problems people face for which
Struts doesn't provide very good support.
Also, I'm probably conflating the specific issue of prefilling a form
with the more general problem of preparing the view. Perhaps it's an
idiosyncracy of my design approach, but I find it more logical to
divide control logic between request processing and response
processing, and I prefer to hook control behavior to a page,
particularly if it's possible that the page may be a destination from
multiple actions. I also find it clearer than the alternative, which
is to use the ActionForm passed to execute in two incompatible
modes--sometimes as a request data source and sometimes as a response
data sink -- depending on the particular case.
We developed a home grown solution for hooking control behavior to
pages (essentially to forwards) and found it a tidy way to organize
things. There have been extensive past discussions on
"ViewControllers" which lead me to believe that at least a few people
would appreciate support for this, and since it's all addition, it
seems like a reasonable thing to add. People who prefer to do
everything in their Action classes can, and people who prefer the
split can have the split.
In reviewing the page preparation control logic in this app, it's
true that most of it is not form prefilling, but for us it was also
more common than seems to have been the case in your apps.
Joe
At 6:09 PM -0500 3/17/05, Rick Reumann wrote:
> o C) The form on Page 2 needs to be populated with data that is
>DEPENDENT on what the user submited on the form on page 1. [I
>believe this is the case you and Joe are most concerned with?] The
>problem is that you now need to create an instance of the ActionForm
>that you need on page 2 and populate it in the Action that form 1
>submits to OR, what I'd probably do, is... after I'm done processing
>what I need in my first Action, I'd stuff the values that I needed
>in the next action back into the request and foward to my next
>action like in step B above. Of course I might have a different
>dispatch method for this for when I know I'd be coming from this
>type of scenario. Maybe something like processFromXXX or something
>like that. I think the difference in the approaches is that you'd
>want to leave the 1st Action and go right to the next page (with a
>new form) whereas I think it's more clean to foward to the
>approriate action to take care of any prepopulation (even if based
>on params from an earlier request). With this later approach you
>don't need to worry aobut creating the correct ActionForm instance.
>
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multiple ActionForms per ActionMapping
Posted by Dakota Jack <da...@gmail.com>.
The situation you describe as the one in point is correct. However,
the whole point is to use one and not two actions. There is no
problem if you use two actions. But, then you have to chain actions.
Jack
On Thu, 17 Mar 2005 18:09:26 -0500, Rick Reumann <st...@reumann.net> wrote:
> Dakota Jack wrote the following on 3/17/2005 4:20 PM:
> > I am with Joe on this one. This situation is, at least for me, the
> > most common situation I face. Every page except the welcome page has
> > input for me.
>
> Sorry, I'm not bringing this to the dev list because I'm first just
> trying to understand what exactly is the 'common situation'. I don't
> think your wiki post explains the problem very well (granted I'm dense,
> so bare with me.) The wiki states:
>
> "The most common use case that I know of is when we go from one page to
> another page on the browser, sending the server certain request values
> from the first page and getting from the server certain response values
> on the second page. Most pages have both input data (setup) and output
> data (request name/value pairs).
>
> I presume that we are using Struts, so the first page and the second
> page will each have different <html:form> values."
>
> If I'm understanding you correctly, the only time I find the above is
> slighlty problematic is when what needs to be populated on "Page 2" is
> directly dictated by what was submited on "Page 1." If this is the
> case, I certainly wouldn't say that is the most common problem in
> relation to form submits.
>
> I tend to think the order of most common scenarios (in relation to form
> submits) would be...
>
> 1) User submits a form. Result page needs to display some sort of
> results based on the form info submitted. This could be a simple
> cofirmation message or maybe a results page with a list of employees,
> car types, or some financial results. Typically this page is also
> interactive in the sense you could often click on an employee or car
> name to get more info. [I'd hopefully be correct in assuming this first
> scenario is unaffected by the problem you are proposing?]
>
> 2) User submits form. After processing the data, the user needs to be
> brought to another form where he/she will enter in more information.
> This scenario falls into three basic types in how the two forms are
> related...
>
> o A) Form 2 (page 2) does not need to be prepopulated with anything
> special. The simple default values in the ActionForm backing the page
> are good enough.
> - in this case after form 1 submits it's as simple as doing a
> typical forward to the jsp holding form 2
>
> o B) Page 2 needs to have some prepopulation take place.
> - This is a case for when I think forwarding to another Action is
> just fine. So when form1 submitted, my "success" foward would simply
> equate to the Action mapping needed for page 2:
>
> <forward name="success" path="/carStuff.do?dispatch=setUp"/>
>
> o C) The form on Page 2 needs to be populated with data that is
> DEPENDENT on what the user submited on the form on page 1. [I believe
> this is the case you and Joe are most concerned with?] The problem is
> that you now need to create an instance of the ActionForm that you need
> on page 2 and populate it in the Action that form 1 submits to OR, what
> I'd probably do, is... after I'm done processing what I need in my first
> Action, I'd stuff the values that I needed in the next action back into
> the request and foward to my next action like in step B above. Of course
> I might have a different dispatch method for this for when I know I'd be
> coming from this type of scenario. Maybe something like processFromXXX
> or something like that. I think the difference in the approaches is that
> you'd want to leave the 1st Action and go right to the next page (with a
> new form) whereas I think it's more clean to foward to the approriate
> action to take care of any prepopulation (even if based on params from
> an earlier request). With this later approach you don't need to worry
> aobut creating the correct ActionForm instance.
>
> *I guess my question is what scenario are you guys mentioning that is
> common for the cause of this concern? I'm guessing it is step 2.C above?
> With the preponderance of possible struts questions that come along this
> certainly is not 'that' common. I don't see that many applications where
> every page is a form and each form's population of fields is that
> intricately tied to what was submitted on the previous form. (Exception
> of course is wizard based applications - like steps to filling out
> online taxes, which in that case, I think one ActionForm across requests
> is the cleanest approach).
>
> I'm not trying to be a pain, but I'm sure I'm not the only one that is
> slightly confused by the problem statement that you are posing on the
> wiki page.
>
>
> And, I have to redirect the welcome page because I need
> > data there too. I bet if you looked at the posts to the users list
> > seriatim you would find that a very surprising percentage of posts
> > would center on this problem. I know that it can be solved
> > programmatically, Rick, but think that this is something the framework
> > should do.
> >
> > I agree that ActionForms should be associated with page forms. That
> > is why I think this should happen.
> >
> > Jack
> >
> > http://wiki.apache.org/struts/StrutsMultipleActionForms
> >
> >
> > On Thu, 17 Mar 2005 15:05:28 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> >
> >>I find this a quite common experience, and I just posted a response
> >>to Jack on the dev list outlining the direction I intend to take to
> >>provide a solution. Also, as noted on the dev list, now that Struts
> >>1.3 allows you to easily configure arbitrary String properties on
> >>ActionMapping (ActionConfig) means that it should be relatively
> >>straightforward to add properties like "responseform.name" and
> >>"responseform.scope" and do whatever you want with them.
> >>
> >>I'm afraid that in the current Struts model, there are still quite a
> >>few things to juggle to get an ActionForm instance. At the bare
> >>minimum, you need an HttpServletRequest (and from it, a ModuleConfig
> >>and possibly the session) and two Strings.
> >>
> >>I think it would be nice to make it very clear how to get an instance
> >>with out having to juggle all of these. It would be possible, for
> >>instance, to add a method to ActionContext (which encapsulates the
> >>request scope, the session scope, and the module config) which would
> >>take two String arguments and return an ActionForm. I think some
> >>would object to putting that much behavior in ActionContext, so an
> >>alternative would be to pick a Utils class (or maybe the
> >>ModuleConfig) and pass it the ActionContext and two strings.
> >>
> >>If you're interested in the issue, though, let's continue the
> >>discussion on "dev" (thread subject: "ActionConfig property map and
> >>form setup strategies (Re: POJO Actions and the ActionCommand
> >>interface)")
> >>
> >>Joe
> >>
> >>At 2:50 PM -0500 3/17/05, Rick Reumann wrote:
> >>
> >>>Rick Reumann wrote the following on 3/17/2005 2:29 PM:
> >>>
> >>>
> >>>>Convincing me that 'more' ActionForms are a good thing is going to
> >>>>be a difficult task, but restate or post your summary propostion
> >>>>and I'll 'attempt' to look at it without any preconceived notions
> >>>>that you might be crazy:)
> >>>
> >>>Jack, I saw your post here on the dev list, and I believe I know the
> >>>problem you are talking about. Yes, I have run into the annoying
> >>>situation where you have a new form you need to set for the
> >>>resulting page you will be forwarded to. I'd argue though that this
> >>>isn't "that" common of occurrence and when it does occur I don't
> >>>find it that big of a deal to just manually instantiate the form
> >>>that I'll need (in the first action) and stuff it into scope so it's
> >>>ready for the ensuing jsp to use. (I could be wrong, though, in
> >>>understanding the situation you are concerned with.)
> >>
> >>--
> >>Joe Germuska
> >>Joe@Germuska.com
> >>http://blog.germuska.com
> >>"Narrow minds are weapons made for mass destruction" -The Ex
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >
> >
> >
>
> --
> Rick
>
> ---------------------------------------------------------------------
> 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: Multiple ActionForms per ActionMapping
Posted by Dakota Jack <da...@gmail.com>.
Exactly, if I understand you Leon. Using two actions is a hack. The
natural thing is one action. There is no reason at all to use two
actions.
Jack
On Fri, 18 Mar 2005 00:44:55 +0100, Leon Rosenberg
<st...@anotheria.net> wrote:
> > * I could read from the database in the first Action
> > (delegate to some business class hopefully!) and stick it
> > directly in Request. But that breaks isolation between the
> > pages. The Action associated with one page should not set up
> > for another.
>
> One thing I don't understand...
> The actions and the jsps are already connected to each other by the use-case
> and the requirement
> that the second action/jsp depends on the first. The use case could even go
> so far, that the
> first action have to decide whether to show the second action at all
> dependent on what the user entered
> there, right (Like in do you want additional insurance contract when you buy
> a car)?
>
> Or it could decide whether to forward to action 2a or action 2b and
> therefore influence the flow of events
> in this use case.
>
> What I don't understand is, why we should isolate two actions, which are
> tied to each other by definition?
>
> I think a wizard, and we are talking about wizards, as Rick explained in his
> mail, which was much better phrased as mine,
> is not only a collection of forms, but also the flow of control inbetween
> the forms.
> Why should I break this natural dependency?
>
> Regards
> Leon
>
>
> ---------------------------------------------------------------------
> 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: Multiple ActionForms per ActionMapping
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Fri, March 18, 2005 10:42 am, Rick Reumann said:
> No, you are correct and sorry for the confusion.
No worries mate! :)
> Yes there is some over head if you have to forward to the setup of
> another action (vs going right to the JSP), but to me that's a small
> price to pay for having a clean consistent way of doing things - (All
> entries to X page go through X DispatchAction or even X SetUpAction if
> you hate the Dispatch).
I tend to agree the overhead isn't a huge concern in a great many
instances. It's when you start talking about very high availability and
scalability requirements that every little bit counts. Obviously you can
always throw hardware at things like this and render moot any debate about
whether an extra request here or there matters. And while I agree with
you that what you suggest really isn't all that ugly, if there is a
solution that is even a little cleaner (a subjective debate to be sure)
*as well as* avoids that overhead, it's worth discussing. :)
> Rick
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multiple ActionForms per ActionMapping
Posted by Rick Reumann <st...@reumann.net>.
Frank W. Zammetti wrote the following on 3/17/2005 10:19 PM:
> I could be wrong here, so feel free to educate me if so... if I return a
> forward from an Action that is a typical forward that references a JSP,
> the request is essentially done being handled at that point, right? What
> I mean by that is that a not much else happens after that, just a
> typical RequestDispatcher being used to transfer control to that page.
> Looking at the 1.2.6 RequestProcessor verifies this is accurate (unless
> I'm wrong!)
No, you are correct and sorry for the confusion. I guess I was thinking
more along the lines that your entry point to "Page 2" will not always
be coming directly from the results of your Action that Page 1 submitted
to. (At least I doubt that would always be the case, since you guys are
aguing for extremely flexible approaches). That being said, you will
usually have a mapping set up that gets you to Page 2 and that of course
will use, at the very least, a simple forward action which is a controller.
Yes there is some over head if you have to forward to the setup of
another action (vs going right to the JSP), but to me that's a small
price to pay for having a clean consistent way of doing things - (All
entries to X page go through X DispatchAction or even X SetUpAction if
you hate the Dispatch).
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Redirect work only with browser?
Posted by Erik Weber <er...@mindspring.com>.
Jim Theodoridis wrote:
> Erik Weber wrote:
>
>>
>>
>> Jim Theodoridis wrote:
>>
>>> Sorry it is a new message
>>>
>>> In an action i am having the following path = ".....";
>>> a.setRedirect(true);
>>> a.setPath(path.toString());
>>> ..........
>>>
>>> at the path assing a URL as http://www.yahoo.com or
>>> http://www.google.com
>>> I want my action to access some informations from a database using a
>>> parameter for example text
>>>
>>> http://www.myportal.com/myaction.do?text=jim
>>>
>>> and then to pass that informations to the URL
>>> When i test my application with a browser everything works fine
>>>
>>> If I want someone to sent some informations to my action for example
>>>
>>> http://www.myportal.com/myaction.do?text=jim
>>>
>>> and then myaction using the parameter text to access a database and
>>> retrive some informations
>>> and then to post those informations to a URL as assigned to variable
>>> path it doesnot work.
>>> The redirect works only with a browser?
>>
>>
>>
>>
>> What other agent are you using besides a browser? Perhaps it doesn't
>> understand how to follow a redirect response?
>>
>> Erik
>>
> I want to sent a message with mobile phone to a MO number then the
> providor sents that message to my URL as parameters
> My action takes some information from a database according to
> parameters and then sents those informations to another URL of the
> providor to sent the information back to mobile phone.
>
>
In a normal HTTP request/response, the agent sends a request for a
document and then *renders* what ever comes back in the response body,
expecting it to be the document.
When a redirect response is sent back to the agent, however, it has to
be smart enough to understand that the response body does not contain
the document but rather contains further instructions on how to obtain
the document. If the agent doesn't understand how to interpret a
redirect response, it might simply try to render the redirect response,
thinking that the response body contains the document. The response body
is going to be empty, however, so the agent will probably just render a
blank screen.
Not sure if that's the problem but I just wanted to make sure you were
aware of that.
Erik
>
> ---------------------------------------------------------------------
> 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: Redirect work only with browser?
Posted by Jim Theodoridis <st...@tera.gr>.
Erik Weber wrote:
>
>
> Jim Theodoridis wrote:
>
>> Sorry it is a new message
>>
>> In an action i am having the following path = ".....";
>> a.setRedirect(true);
>> a.setPath(path.toString());
>> ..........
>>
>> at the path assing a URL as http://www.yahoo.com or
>> http://www.google.com
>> I want my action to access some informations from a database using a
>> parameter for example text
>>
>> http://www.myportal.com/myaction.do?text=jim
>>
>> and then to pass that informations to the URL
>> When i test my application with a browser everything works fine
>>
>> If I want someone to sent some informations to my action for example
>>
>> http://www.myportal.com/myaction.do?text=jim
>>
>> and then myaction using the parameter text to access a database and
>> retrive some informations
>> and then to post those informations to a URL as assigned to variable
>> path it doesnot work.
>> The redirect works only with a browser?
>
>
>
> What other agent are you using besides a browser? Perhaps it doesn't
> understand how to follow a redirect response?
>
> Erik
>
I want to sent a message with mobile phone to a MO number then the
providor sents that message to my URL as parameters
My action takes some information from a database according to parameters
and then sents those informations to another URL of the providor to sent
the information back to mobile phone.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Redirect work only with browser?
Posted by Erik Weber <er...@mindspring.com>.
Jim Theodoridis wrote:
> Sorry it is a new message
>
> In an action i am having the following path = ".....";
> a.setRedirect(true);
> a.setPath(path.toString());
> ..........
>
> at the path assing a URL as http://www.yahoo.com or http://www.google.com
> I want my action to access some informations from a database using a
> parameter for example text
>
> http://www.myportal.com/myaction.do?text=jim
>
> and then to pass that informations to the URL
> When i test my application with a browser everything works fine
>
> If I want someone to sent some informations to my action for example
>
> http://www.myportal.com/myaction.do?text=jim
>
> and then myaction using the parameter text to access a database and
> retrive some informations
> and then to post those informations to a URL as assigned to variable
> path it doesnot work.
> The redirect works only with a browser?
What other agent are you using besides a browser? Perhaps it doesn't
understand how to follow a redirect response?
Erik
>
>>
>
>
>
> ---------------------------------------------------------------------
> 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
Redirect work only with browser?
Posted by Jim Theodoridis <st...@tera.gr>.
Sorry it is a new message
In an action i am having the following
path = ".....";
a.setRedirect(true);
a.setPath(path.toString());
..........
at the path assing a URL as http://www.yahoo.com or http://www.google.com
I want my action to access some informations from a database using a
parameter for example text
http://www.myportal.com/myaction.do?text=jim
and then to pass that informations to the URL
When i test my application with a browser everything works fine
If I want someone to sent some informations to my action for example
http://www.myportal.com/myaction.do?text=jim
and then myaction using the parameter text to access a database and
retrive some informations
and then to post those informations to a URL as assigned to variable
path it doesnot work.
The redirect works only with a browser?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multiple ActionForms per ActionMapping
Posted by Jim Theodoridis <st...@tera.gr>.
Hello
In an action i am having the following
path = ".....";
a.setRedirect(true);
a.setPath(path.toString());
..........
at the path assing a URL as http://www.yahoo.com or http://www.google.com
I want my action to access some informations from a database using a
parameter for example text
http://www.myportal.com/myaction.do?text=jim
and then to pass that informations to the URL
When i test my application with a browser everything works fine
If I want someone to sent some informations to my action for example
http://www.myportal.com/myaction.do?text=jim
and then myaction using the parameter text to access a database and
retrive some informations
and then to post those informations to a URL as assigned to variable
path it doesnot work.
The redirect works only with a browser?
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multiple ActionForms per ActionMapping
Posted by Dakota Jack <da...@gmail.com>.
<SNIP>
On Sat, 19 Mar 2005 10:19:31 +0530, Vamsee Kanakala <va...@gmail.com> wrote:
> Joe Germuska wrote:
>
> > I don't know if we've all landed on most people's kill-filters or
> > what, but one gets the sense that what some of us are interested in
> > arguing thoroughly about is of little import to regular users.
> >
> I'm as 'regular' a user as you can get, but I thoroughly enjoy these
> technical discussions. For me, it's very educational. I don't understand
> everything, but I feel really happy when I do. To use a cliche, I can
> "stand on the shoulders of giants". I might not go and start playing
> with 1.3 right now, but one of these days, I will muster enough courage
> to do so. Please do whatever you're doing, it's working ;)
>
> Vamsee.
</SNIP>
I get the sense that a lot of "regular" users have these concerns,
Joe. I would guess you do the same thing, but I spend a great deal of
time sort of "watching" and making notes on the "regular" users on
this list.
Jack
--
"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: Multiple ActionForms per ActionMapping
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Fri, March 18, 2005 1:53 am, Dakota Jack said:
> You can do anything like this, I think. But, you can do this sort of
> thing without chain too. What I mean, Frank, is that if you can list
> two ActionForms in your <action-mapping> then that would be good.
> This is just a KISS principle, which I really believe in, and I know
> you do too.
Without question I agree, KISS is the way to go in almost every instance.
I was really just anticipating the response from the "1.3 solves this
problem!" crowd. And frankly, they are right, the problem *is* solved in
1.3, to my satisfaction anyway. But, it doesn't help anyone not using or
moving to 1.3, which clearly is the vast majority right now.
> Jack
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multiple ActionForms per ActionMapping
Posted by Dakota Jack <da...@gmail.com>.
You can do anything like this, I think. But, you can do this sort of
thing without chain too. What I mean, Frank, is that if you can list
two ActionForms in your <action-mapping> then that would be good.
This is just a KISS principle, which I really believe in, and I know
you do too.
Jack
On Thu, 17 Mar 2005 23:05:34 -0500, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> Well, I could certainly be wrong, but based on what others have said
> related to this matter, my understanding is that you can define a Chain
> in the chain-config file and then reference that chain on an Action
> mapping so that in essence you execute a Chain instead of an Action if
> you want.
>
> Can someone tell me for sure whether I have an incorrect understanding
> or not? And let me just say that if I am in fact incorrect, wouldn't
> THAT be exactly what SHOULD be possible in 1.3? To me, being able to
> alter the basic request processing pipeline is cool (my Struts Web
> Services project becomes very easy then), but the thing I really saw as
> interesting down the road was being able to create a Chain and have it
> execute where I would only have a single Action in "classic" Struts.
>
> I look forward to an answer on this...
>
> Frank
>
> Dakota Jack wrote:
> > The composable request processor has nothing to do with setting up the
> > <action-mapping> so far as I know, and applicatoin level uses of Chain
> > are irrelevant. So, v1.3 does not have any more of a framework level
> > solution than does v1.2.x. No?
> >
> > Jack
> >
> >
> > On Thu, 17 Mar 2005 22:34:10 -0500, Frank W. Zammetti
> > <fz...@omnytex.com> wrote:
> >
> >>Dakota Jack wrote:
> >> > I think everyone has built solutions to the problem. But, the problem
> >> > should be solved on the framework level, in my opinion.
> >>
> >>And I would be one to agree with that.
> >>
> >>But, here's the problem I think...
> >>
> >>1.3 offers a framework-level solution for this. In fact, it's the core
> >>of what 1.3 is!
> >>
> >>But, since we know that new features won't be added to anything prior to
> >>1.3, getting a solution in the framework level in the current releases
> >>isn't an option, right?
> >>
> >>So, we either need (a) a non-intrusive solution that can be added as an
> >>extension to do this or (b) come up with an agreeable pattern and
> >>recommend people use that if they aren't using 1.3.
> >>
> >>Frank
> >>
> >>
> >>>Jack
> >>>
> >>>
> >>>On Thu, 17 Mar 2005 22:19:06 -0500, Frank W. Zammetti
> >>><fz...@omnytex.com> wrote:
> >>>
> >>>
> >>>>Rick Reumann wrote:
> >>>>
> >>>>
> >>>>>First off, if you are using Struts you are always going through a
> >>>>>controller, even if the basic FowardAction, so even when you say you are
> >>>>>going "immediately" to another page you are still going through a
> >>>>>controller.
> >>>>
> >>>>I could be wrong here, so feel free to educate me if so... if I return a
> >>>>forward from an Action that is a typical forward that references a JSP,
> >>>>the request is essentially done being handled at that point, right?
> >>>>What I mean by that is that a not much else happens after that, just a
> >>>>typical RequestDispatcher being used to transfer control to that page.
> >>>>Looking at the 1.2.6 RequestProcessor verifies this is accurate (unless
> >>>>I'm wrong!)
> >>>>
> >>>>By contrast, if the forward references another Action mapping, the whole
> >>>>request cycle starts anew, through ActionServlet, through the
> >>>>RequestProcessor, through everything that goes into the whole request
> >>>>processing flow, doesn't it? That's the overhead I was talking about.
> >>>>Now, I'm not willing to say this is a significant problem, but it is a
> >>>>true statement I believe and will certainly have an impact on
> >>>>scalability concerns (as does anything done on the server)
> >>>>
> >>>>In this regard, I don't believe it is accurate to say you are "always
> >>>>going through a controller", indeed it seems to definitely not be the
> >>>>case when forwarding directly to a JSP. :)
> >>>>
> >>>>
> >>>>
> >>>>>Second, the next page obviously has a form on it and that form will
> >>>>>submit to an Action. So why is it such a big deal to have a setUp
> >>>>>dispatch method there? And once you have that setUp method in there
> >>>>>(which sets up your drop downs), it's just a matter of fowarding to this
> >>>>>action and giving it the dispatch setUp parameter.
> >>>>
> >>>>Well, for one thing I am in the camp of folks who thinks DispatchActions
> >>>>aren't a great idea, but that's really a very minor point here... I
> >>>>would still consider that additional overhead to be something I'd prefer
> >>>>to avoid.
> >>>>
> >>>>
> >>>>
> >>>>>I'm actually suprised you guys think this is such a big deal. The
> >>>>>situation C that I brought up a couple posts back is much more of
> >>>>>annoying problem and I thought that's what you were talking about.
> >>>>
> >>>>I'm not sure how big a deal I really think it is, and if I previously
> >>>>said it was a big deal then I probably was making more of it than it is.
> >>>> What I do agree with is that this is a typical scenario faced by
> >>>>developers fairly frequently, and therefore a standard approach to it
> >>>>that we all agree is good to put up as a recommendation is probably a
> >>>>good idea. I agree with Jack that I don't see where there is a really
> >>>>good solution in existance now. You are making the argument that the
> >>>>Action chaining approach *is* actually a good one. While I don't think
> >>>>it rises to the level of writing the Linux kernel in Logo, I wouldn't
> >>>>agree that it is an optimal solution. :)
> >>>>
> >>>>
> >>>>
> >>>>>Pages submit to DispatchAction methods. Most actions have a prep method
> >>>>>(setUp concept) used to set up the request (or the form) with any
> >>>>>necessary items. If you need to get to page that needs something
> >>>>>preped/setup then simply make sure you go through the appropriate
> >>>>>DispatchAction prep method. Are there more flexible solutions out
> >>>>>there? I'm sure there are. The above has been working fine for me though.
> >>>>
> >>>>I would suggest adding that approach to the Wiki page! If it is working
> >>>>that well for you, then it is certainly a relevant addition that may
> >>>>help others.
> >>>>
> >>>>It's probably not worth debating how one solution compares to another
> >>>>because they all have their benefits and problems, but we all seem to be
> >>>>agreeing that the optimal solution hasn't been put forward yet (remember
> >>>>we're ignoring 1.3 and chain in this discussion). Also how big a
> >>>>problem it actually is doesn't seem very important. It *is* clearly
> >>>>faced by people to one degree or another, so posting various approaches
> >>>>is a worthwild exercise in my opinion.
> >>>>
> >>>>--
> >>>>Frank W. Zammetti
> >>>>Founder and Chief Software Architect
> >>>>Omnytex Technologies
> >>>>http://www.omnytex.com
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>>>For additional commands, e-mail: user-help@struts.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>--
> >>Frank W. Zammetti
> >>Founder and Chief Software Architect
> >>Omnytex Technologies
> >>http://www.omnytex.com
> >>
> >>
> >
> >
> >
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
>
--
"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: Multiple ActionForms per ActionMapping
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Fri, March 18, 2005 6:53 am, Joe Germuska said:
> Frank, you have a correct understanding.
Well, even a blind cat finds the litter box every now and again :) Good
to know I got it!
> In this specific case, my concern is that specifics of Jack's
> implementation seem unique to his coding approach in a way which
> would be inappropriate to integrate directly into the core.
I would agree because even though I agree with Jack on the need for a
standard solution (be it a change to the core or just a recommended
pattern), I'm not sure which solution I would be in favor of overall.
But, as has been said, 1.3 solves this problem (and in a way that is
satisfactory to me, mostly), and that being the case, coupled with the
stated fact that 1.2 won't have new features added, would seem to indicate
that discussing anything other than patterns to this problem (or offering
optional extensions to the core as I've done) is really the only choice.
> If only
> a few other people would speak up in favor of the same features (and
> implementations), it would be easier to decide to add those features.
> In a case like this, publishing code and encouraging people to try it
> out locally is a good route to that, and I think that some of the
> features in Struts 1.3 make it easier to publish something for people
> to use as an alternative to try out while an idea builds up the wider
> interest that makes it a clear candidate for addition to the core.
These comments kind of dovetail in to something...
We're at a very ackward time as far as Struts goes I think... 1.3 is
coming, probably not too far off, but not here yet. My suspicion is that
not very many people outside the development team (and those around them
in their day jobs I imagine) are using it. Certainly I haven't seem
indications of many outside the team playing with it yet.
With the end of development of the 1.2 versions, that means all the ideas
being tossed around should be going into the 1.3 version, but not everyone
(and I believe not many) are willing to do that yet. So, a lot of ideas
aren't getting the full shakedown they should. I also think this is why
we're seeing more discussion than actual implementation lately: people
just don't know or aren't quite ready to play with 1.3, and there is no
incentive to do anything with 1.2, so nothing happens besides talk.
Just a commentary, and maybe my observations are flawed to being with.
Certainly I offer no solution to any of this even if I'm right :)
> I don't know if we've all landed on most people's kill-filters or
> what, but one gets the sense that what some of us are interested in
> arguing thoroughly about is of little import to regular users.
I'm not so sure I'd draw that conclusion based on no comment from other
than a few of us, but, it's pretty hard to get anything done without
sigificant backing, so it might be the right conclusion by default :)
> Joe
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multiple ActionForms per ActionMapping
Posted by Vamsee Kanakala <va...@gmail.com>.
Joe Germuska wrote:
> I don't know if we've all landed on most people's kill-filters or
> what, but one gets the sense that what some of us are interested in
> arguing thoroughly about is of little import to regular users.
>
I'm as 'regular' a user as you can get, but I thoroughly enjoy these
technical discussions. For me, it's very educational. I don't understand
everything, but I feel really happy when I do. To use a cliche, I can
"stand on the shoulders of giants". I might not go and start playing
with 1.3 right now, but one of these days, I will muster enough courage
to do so. Please do whatever you're doing, it's working ;)
Vamsee.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multiple ActionForms per ActionMapping
Posted by Joe Germuska <Jo...@Germuska.com>.
At 11:05 PM -0500 3/17/05, Frank W. Zammetti wrote:
>Well, I could certainly be wrong, but based on what others have said
>related to this matter, my understanding is that you can define a
>Chain in the chain-config file and then reference that chain on an
>Action mapping so that in essence you execute a Chain instead of an
>Action if you want.
>
>Can someone tell me for sure whether I have an incorrect
>understanding or not? And let me just say that if I am in fact
>incorrect, wouldn't THAT be exactly what SHOULD be possible in 1.3?
>To me, being able to alter the basic request processing pipeline is
>cool (my Struts Web Services project becomes very easy then), but
>the thing I really saw as interesting down the road was being able
>to create a Chain and have it execute where I would only have a
>single Action in "classic" Struts.
Frank, you have a correct understanding. Jack's point (dare I
attempt to paraphrase?) is that if there is a feature or strategy
which many different users of the framework repeatedly have to code
local solutions, then it makes sense to consider implementing the
best of those solutions into the framework.
In this specific case, my concern is that specifics of Jack's
implementation seem unique to his coding approach in a way which
would be inappropriate to integrate directly into the core. If only
a few other people would speak up in favor of the same features (and
implementations), it would be easier to decide to add those features.
In a case like this, publishing code and encouraging people to try it
out locally is a good route to that, and I think that some of the
features in Struts 1.3 make it easier to publish something for people
to use as an alternative to try out while an idea builds up the wider
interest that makes it a clear candidate for addition to the core.
I don't know if we've all landed on most people's kill-filters or
what, but one gets the sense that what some of us are interested in
arguing thoroughly about is of little import to regular users.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multiple ActionForms per ActionMapping
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Well, I could certainly be wrong, but based on what others have said
related to this matter, my understanding is that you can define a Chain
in the chain-config file and then reference that chain on an Action
mapping so that in essence you execute a Chain instead of an Action if
you want.
Can someone tell me for sure whether I have an incorrect understanding
or not? And let me just say that if I am in fact incorrect, wouldn't
THAT be exactly what SHOULD be possible in 1.3? To me, being able to
alter the basic request processing pipeline is cool (my Struts Web
Services project becomes very easy then), but the thing I really saw as
interesting down the road was being able to create a Chain and have it
execute where I would only have a single Action in "classic" Struts.
I look forward to an answer on this...
Frank
Dakota Jack wrote:
> The composable request processor has nothing to do with setting up the
> <action-mapping> so far as I know, and applicatoin level uses of Chain
> are irrelevant. So, v1.3 does not have any more of a framework level
> solution than does v1.2.x. No?
>
> Jack
>
>
> On Thu, 17 Mar 2005 22:34:10 -0500, Frank W. Zammetti
> <fz...@omnytex.com> wrote:
>
>>Dakota Jack wrote:
>> > I think everyone has built solutions to the problem. But, the problem
>> > should be solved on the framework level, in my opinion.
>>
>>And I would be one to agree with that.
>>
>>But, here's the problem I think...
>>
>>1.3 offers a framework-level solution for this. In fact, it's the core
>>of what 1.3 is!
>>
>>But, since we know that new features won't be added to anything prior to
>>1.3, getting a solution in the framework level in the current releases
>>isn't an option, right?
>>
>>So, we either need (a) a non-intrusive solution that can be added as an
>>extension to do this or (b) come up with an agreeable pattern and
>>recommend people use that if they aren't using 1.3.
>>
>>Frank
>>
>>
>>>Jack
>>>
>>>
>>>On Thu, 17 Mar 2005 22:19:06 -0500, Frank W. Zammetti
>>><fz...@omnytex.com> wrote:
>>>
>>>
>>>>Rick Reumann wrote:
>>>>
>>>>
>>>>>First off, if you are using Struts you are always going through a
>>>>>controller, even if the basic FowardAction, so even when you say you are
>>>>>going "immediately" to another page you are still going through a
>>>>>controller.
>>>>
>>>>I could be wrong here, so feel free to educate me if so... if I return a
>>>>forward from an Action that is a typical forward that references a JSP,
>>>>the request is essentially done being handled at that point, right?
>>>>What I mean by that is that a not much else happens after that, just a
>>>>typical RequestDispatcher being used to transfer control to that page.
>>>>Looking at the 1.2.6 RequestProcessor verifies this is accurate (unless
>>>>I'm wrong!)
>>>>
>>>>By contrast, if the forward references another Action mapping, the whole
>>>>request cycle starts anew, through ActionServlet, through the
>>>>RequestProcessor, through everything that goes into the whole request
>>>>processing flow, doesn't it? That's the overhead I was talking about.
>>>>Now, I'm not willing to say this is a significant problem, but it is a
>>>>true statement I believe and will certainly have an impact on
>>>>scalability concerns (as does anything done on the server)
>>>>
>>>>In this regard, I don't believe it is accurate to say you are "always
>>>>going through a controller", indeed it seems to definitely not be the
>>>>case when forwarding directly to a JSP. :)
>>>>
>>>>
>>>>
>>>>>Second, the next page obviously has a form on it and that form will
>>>>>submit to an Action. So why is it such a big deal to have a setUp
>>>>>dispatch method there? And once you have that setUp method in there
>>>>>(which sets up your drop downs), it's just a matter of fowarding to this
>>>>>action and giving it the dispatch setUp parameter.
>>>>
>>>>Well, for one thing I am in the camp of folks who thinks DispatchActions
>>>>aren't a great idea, but that's really a very minor point here... I
>>>>would still consider that additional overhead to be something I'd prefer
>>>>to avoid.
>>>>
>>>>
>>>>
>>>>>I'm actually suprised you guys think this is such a big deal. The
>>>>>situation C that I brought up a couple posts back is much more of
>>>>>annoying problem and I thought that's what you were talking about.
>>>>
>>>>I'm not sure how big a deal I really think it is, and if I previously
>>>>said it was a big deal then I probably was making more of it than it is.
>>>> What I do agree with is that this is a typical scenario faced by
>>>>developers fairly frequently, and therefore a standard approach to it
>>>>that we all agree is good to put up as a recommendation is probably a
>>>>good idea. I agree with Jack that I don't see where there is a really
>>>>good solution in existance now. You are making the argument that the
>>>>Action chaining approach *is* actually a good one. While I don't think
>>>>it rises to the level of writing the Linux kernel in Logo, I wouldn't
>>>>agree that it is an optimal solution. :)
>>>>
>>>>
>>>>
>>>>>Pages submit to DispatchAction methods. Most actions have a prep method
>>>>>(setUp concept) used to set up the request (or the form) with any
>>>>>necessary items. If you need to get to page that needs something
>>>>>preped/setup then simply make sure you go through the appropriate
>>>>>DispatchAction prep method. Are there more flexible solutions out
>>>>>there? I'm sure there are. The above has been working fine for me though.
>>>>
>>>>I would suggest adding that approach to the Wiki page! If it is working
>>>>that well for you, then it is certainly a relevant addition that may
>>>>help others.
>>>>
>>>>It's probably not worth debating how one solution compares to another
>>>>because they all have their benefits and problems, but we all seem to be
>>>>agreeing that the optimal solution hasn't been put forward yet (remember
>>>>we're ignoring 1.3 and chain in this discussion). Also how big a
>>>>problem it actually is doesn't seem very important. It *is* clearly
>>>>faced by people to one degree or another, so posting various approaches
>>>>is a worthwild exercise in my opinion.
>>>>
>>>>--
>>>>Frank W. Zammetti
>>>>Founder and Chief Software Architect
>>>>Omnytex Technologies
>>>>http://www.omnytex.com
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>>For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>--
>>Frank W. Zammetti
>>Founder and Chief Software Architect
>>Omnytex Technologies
>>http://www.omnytex.com
>>
>>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multiple ActionForms per ActionMapping
Posted by Dakota Jack <da...@gmail.com>.
The composable request processor has nothing to do with setting up the
<action-mapping> so far as I know, and applicatoin level uses of Chain
are irrelevant. So, v1.3 does not have any more of a framework level
solution than does v1.2.x. No?
Jack
On Thu, 17 Mar 2005 22:34:10 -0500, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> Dakota Jack wrote:
> > I think everyone has built solutions to the problem. But, the problem
> > should be solved on the framework level, in my opinion.
>
> And I would be one to agree with that.
>
> But, here's the problem I think...
>
> 1.3 offers a framework-level solution for this. In fact, it's the core
> of what 1.3 is!
>
> But, since we know that new features won't be added to anything prior to
> 1.3, getting a solution in the framework level in the current releases
> isn't an option, right?
>
> So, we either need (a) a non-intrusive solution that can be added as an
> extension to do this or (b) come up with an agreeable pattern and
> recommend people use that if they aren't using 1.3.
>
> Frank
>
> >
> > Jack
> >
> >
> > On Thu, 17 Mar 2005 22:19:06 -0500, Frank W. Zammetti
> > <fz...@omnytex.com> wrote:
> >
> >>Rick Reumann wrote:
> >>
> >>>First off, if you are using Struts you are always going through a
> >>>controller, even if the basic FowardAction, so even when you say you are
> >>>going "immediately" to another page you are still going through a
> >>>controller.
> >>
> >>I could be wrong here, so feel free to educate me if so... if I return a
> >>forward from an Action that is a typical forward that references a JSP,
> >>the request is essentially done being handled at that point, right?
> >>What I mean by that is that a not much else happens after that, just a
> >>typical RequestDispatcher being used to transfer control to that page.
> >>Looking at the 1.2.6 RequestProcessor verifies this is accurate (unless
> >>I'm wrong!)
> >>
> >>By contrast, if the forward references another Action mapping, the whole
> >>request cycle starts anew, through ActionServlet, through the
> >>RequestProcessor, through everything that goes into the whole request
> >>processing flow, doesn't it? That's the overhead I was talking about.
> >>Now, I'm not willing to say this is a significant problem, but it is a
> >>true statement I believe and will certainly have an impact on
> >>scalability concerns (as does anything done on the server)
> >>
> >>In this regard, I don't believe it is accurate to say you are "always
> >>going through a controller", indeed it seems to definitely not be the
> >>case when forwarding directly to a JSP. :)
> >>
> >>
> >>>Second, the next page obviously has a form on it and that form will
> >>>submit to an Action. So why is it such a big deal to have a setUp
> >>>dispatch method there? And once you have that setUp method in there
> >>>(which sets up your drop downs), it's just a matter of fowarding to this
> >>>action and giving it the dispatch setUp parameter.
> >>
> >>Well, for one thing I am in the camp of folks who thinks DispatchActions
> >>aren't a great idea, but that's really a very minor point here... I
> >>would still consider that additional overhead to be something I'd prefer
> >>to avoid.
> >>
> >>
> >>>I'm actually suprised you guys think this is such a big deal. The
> >>>situation C that I brought up a couple posts back is much more of
> >>>annoying problem and I thought that's what you were talking about.
> >>
> >>I'm not sure how big a deal I really think it is, and if I previously
> >>said it was a big deal then I probably was making more of it than it is.
> >> What I do agree with is that this is a typical scenario faced by
> >>developers fairly frequently, and therefore a standard approach to it
> >>that we all agree is good to put up as a recommendation is probably a
> >>good idea. I agree with Jack that I don't see where there is a really
> >>good solution in existance now. You are making the argument that the
> >>Action chaining approach *is* actually a good one. While I don't think
> >>it rises to the level of writing the Linux kernel in Logo, I wouldn't
> >>agree that it is an optimal solution. :)
> >>
> >>
> >>>Pages submit to DispatchAction methods. Most actions have a prep method
> >>>(setUp concept) used to set up the request (or the form) with any
> >>>necessary items. If you need to get to page that needs something
> >>>preped/setup then simply make sure you go through the appropriate
> >>>DispatchAction prep method. Are there more flexible solutions out
> >>>there? I'm sure there are. The above has been working fine for me though.
> >>
> >>I would suggest adding that approach to the Wiki page! If it is working
> >>that well for you, then it is certainly a relevant addition that may
> >>help others.
> >>
> >>It's probably not worth debating how one solution compares to another
> >>because they all have their benefits and problems, but we all seem to be
> >>agreeing that the optimal solution hasn't been put forward yet (remember
> >>we're ignoring 1.3 and chain in this discussion). Also how big a
> >>problem it actually is doesn't seem very important. It *is* clearly
> >>faced by people to one degree or another, so posting various approaches
> >>is a worthwild exercise in my opinion.
> >>
> >>--
> >>Frank W. Zammetti
> >>Founder and Chief Software Architect
> >>Omnytex Technologies
> >>http://www.omnytex.com
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >
> >
> >
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
>
--
"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: Multiple ActionForms per ActionMapping
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Dakota Jack wrote:
> I think everyone has built solutions to the problem. But, the problem
> should be solved on the framework level, in my opinion.
And I would be one to agree with that.
But, here's the problem I think...
1.3 offers a framework-level solution for this. In fact, it's the core
of what 1.3 is!
But, since we know that new features won't be added to anything prior to
1.3, getting a solution in the framework level in the current releases
isn't an option, right?
So, we either need (a) a non-intrusive solution that can be added as an
extension to do this or (b) come up with an agreeable pattern and
recommend people use that if they aren't using 1.3.
Frank
>
> Jack
>
>
> On Thu, 17 Mar 2005 22:19:06 -0500, Frank W. Zammetti
> <fz...@omnytex.com> wrote:
>
>>Rick Reumann wrote:
>>
>>>First off, if you are using Struts you are always going through a
>>>controller, even if the basic FowardAction, so even when you say you are
>>>going "immediately" to another page you are still going through a
>>>controller.
>>
>>I could be wrong here, so feel free to educate me if so... if I return a
>>forward from an Action that is a typical forward that references a JSP,
>>the request is essentially done being handled at that point, right?
>>What I mean by that is that a not much else happens after that, just a
>>typical RequestDispatcher being used to transfer control to that page.
>>Looking at the 1.2.6 RequestProcessor verifies this is accurate (unless
>>I'm wrong!)
>>
>>By contrast, if the forward references another Action mapping, the whole
>>request cycle starts anew, through ActionServlet, through the
>>RequestProcessor, through everything that goes into the whole request
>>processing flow, doesn't it? That's the overhead I was talking about.
>>Now, I'm not willing to say this is a significant problem, but it is a
>>true statement I believe and will certainly have an impact on
>>scalability concerns (as does anything done on the server)
>>
>>In this regard, I don't believe it is accurate to say you are "always
>>going through a controller", indeed it seems to definitely not be the
>>case when forwarding directly to a JSP. :)
>>
>>
>>>Second, the next page obviously has a form on it and that form will
>>>submit to an Action. So why is it such a big deal to have a setUp
>>>dispatch method there? And once you have that setUp method in there
>>>(which sets up your drop downs), it's just a matter of fowarding to this
>>>action and giving it the dispatch setUp parameter.
>>
>>Well, for one thing I am in the camp of folks who thinks DispatchActions
>>aren't a great idea, but that's really a very minor point here... I
>>would still consider that additional overhead to be something I'd prefer
>>to avoid.
>>
>>
>>>I'm actually suprised you guys think this is such a big deal. The
>>>situation C that I brought up a couple posts back is much more of
>>>annoying problem and I thought that's what you were talking about.
>>
>>I'm not sure how big a deal I really think it is, and if I previously
>>said it was a big deal then I probably was making more of it than it is.
>> What I do agree with is that this is a typical scenario faced by
>>developers fairly frequently, and therefore a standard approach to it
>>that we all agree is good to put up as a recommendation is probably a
>>good idea. I agree with Jack that I don't see where there is a really
>>good solution in existance now. You are making the argument that the
>>Action chaining approach *is* actually a good one. While I don't think
>>it rises to the level of writing the Linux kernel in Logo, I wouldn't
>>agree that it is an optimal solution. :)
>>
>>
>>>Pages submit to DispatchAction methods. Most actions have a prep method
>>>(setUp concept) used to set up the request (or the form) with any
>>>necessary items. If you need to get to page that needs something
>>>preped/setup then simply make sure you go through the appropriate
>>>DispatchAction prep method. Are there more flexible solutions out
>>>there? I'm sure there are. The above has been working fine for me though.
>>
>>I would suggest adding that approach to the Wiki page! If it is working
>>that well for you, then it is certainly a relevant addition that may
>>help others.
>>
>>It's probably not worth debating how one solution compares to another
>>because they all have their benefits and problems, but we all seem to be
>>agreeing that the optimal solution hasn't been put forward yet (remember
>>we're ignoring 1.3 and chain in this discussion). Also how big a
>>problem it actually is doesn't seem very important. It *is* clearly
>>faced by people to one degree or another, so posting various approaches
>>is a worthwild exercise in my opinion.
>>
>>--
>>Frank W. Zammetti
>>Founder and Chief Software Architect
>>Omnytex Technologies
>>http://www.omnytex.com
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multiple ActionForms per ActionMapping
Posted by Dakota Jack <da...@gmail.com>.
I think everyone has built solutions to the problem. But, the problem
should be solved on the framework level, in my opinion.
Jack
On Thu, 17 Mar 2005 22:19:06 -0500, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> Rick Reumann wrote:
> > First off, if you are using Struts you are always going through a
> > controller, even if the basic FowardAction, so even when you say you are
> > going "immediately" to another page you are still going through a
> > controller.
>
> I could be wrong here, so feel free to educate me if so... if I return a
> forward from an Action that is a typical forward that references a JSP,
> the request is essentially done being handled at that point, right?
> What I mean by that is that a not much else happens after that, just a
> typical RequestDispatcher being used to transfer control to that page.
> Looking at the 1.2.6 RequestProcessor verifies this is accurate (unless
> I'm wrong!)
>
> By contrast, if the forward references another Action mapping, the whole
> request cycle starts anew, through ActionServlet, through the
> RequestProcessor, through everything that goes into the whole request
> processing flow, doesn't it? That's the overhead I was talking about.
> Now, I'm not willing to say this is a significant problem, but it is a
> true statement I believe and will certainly have an impact on
> scalability concerns (as does anything done on the server)
>
> In this regard, I don't believe it is accurate to say you are "always
> going through a controller", indeed it seems to definitely not be the
> case when forwarding directly to a JSP. :)
>
> > Second, the next page obviously has a form on it and that form will
> > submit to an Action. So why is it such a big deal to have a setUp
> > dispatch method there? And once you have that setUp method in there
> > (which sets up your drop downs), it's just a matter of fowarding to this
> > action and giving it the dispatch setUp parameter.
>
> Well, for one thing I am in the camp of folks who thinks DispatchActions
> aren't a great idea, but that's really a very minor point here... I
> would still consider that additional overhead to be something I'd prefer
> to avoid.
>
> > I'm actually suprised you guys think this is such a big deal. The
> > situation C that I brought up a couple posts back is much more of
> > annoying problem and I thought that's what you were talking about.
>
> I'm not sure how big a deal I really think it is, and if I previously
> said it was a big deal then I probably was making more of it than it is.
> What I do agree with is that this is a typical scenario faced by
> developers fairly frequently, and therefore a standard approach to it
> that we all agree is good to put up as a recommendation is probably a
> good idea. I agree with Jack that I don't see where there is a really
> good solution in existance now. You are making the argument that the
> Action chaining approach *is* actually a good one. While I don't think
> it rises to the level of writing the Linux kernel in Logo, I wouldn't
> agree that it is an optimal solution. :)
>
> > Pages submit to DispatchAction methods. Most actions have a prep method
> > (setUp concept) used to set up the request (or the form) with any
> > necessary items. If you need to get to page that needs something
> > preped/setup then simply make sure you go through the appropriate
> > DispatchAction prep method. Are there more flexible solutions out
> > there? I'm sure there are. The above has been working fine for me though.
>
> I would suggest adding that approach to the Wiki page! If it is working
> that well for you, then it is certainly a relevant addition that may
> help others.
>
> It's probably not worth debating how one solution compares to another
> because they all have their benefits and problems, but we all seem to be
> agreeing that the optimal solution hasn't been put forward yet (remember
> we're ignoring 1.3 and chain in this discussion). Also how big a
> problem it actually is doesn't seem very important. It *is* clearly
> faced by people to one degree or another, so posting various approaches
> is a worthwild exercise in my opinion.
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.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: Multiple ActionForms per ActionMapping
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Rick Reumann wrote:
> First off, if you are using Struts you are always going through a
> controller, even if the basic FowardAction, so even when you say you are
> going "immediately" to another page you are still going through a
> controller.
I could be wrong here, so feel free to educate me if so... if I return a
forward from an Action that is a typical forward that references a JSP,
the request is essentially done being handled at that point, right?
What I mean by that is that a not much else happens after that, just a
typical RequestDispatcher being used to transfer control to that page.
Looking at the 1.2.6 RequestProcessor verifies this is accurate (unless
I'm wrong!)
By contrast, if the forward references another Action mapping, the whole
request cycle starts anew, through ActionServlet, through the
RequestProcessor, through everything that goes into the whole request
processing flow, doesn't it? That's the overhead I was talking about.
Now, I'm not willing to say this is a significant problem, but it is a
true statement I believe and will certainly have an impact on
scalability concerns (as does anything done on the server)
In this regard, I don't believe it is accurate to say you are "always
going through a controller", indeed it seems to definitely not be the
case when forwarding directly to a JSP. :)
> Second, the next page obviously has a form on it and that form will
> submit to an Action. So why is it such a big deal to have a setUp
> dispatch method there? And once you have that setUp method in there
> (which sets up your drop downs), it's just a matter of fowarding to this
> action and giving it the dispatch setUp parameter.
Well, for one thing I am in the camp of folks who thinks DispatchActions
aren't a great idea, but that's really a very minor point here... I
would still consider that additional overhead to be something I'd prefer
to avoid.
> I'm actually suprised you guys think this is such a big deal. The
> situation C that I brought up a couple posts back is much more of
> annoying problem and I thought that's what you were talking about.
I'm not sure how big a deal I really think it is, and if I previously
said it was a big deal then I probably was making more of it than it is.
What I do agree with is that this is a typical scenario faced by
developers fairly frequently, and therefore a standard approach to it
that we all agree is good to put up as a recommendation is probably a
good idea. I agree with Jack that I don't see where there is a really
good solution in existance now. You are making the argument that the
Action chaining approach *is* actually a good one. While I don't think
it rises to the level of writing the Linux kernel in Logo, I wouldn't
agree that it is an optimal solution. :)
> Pages submit to DispatchAction methods. Most actions have a prep method
> (setUp concept) used to set up the request (or the form) with any
> necessary items. If you need to get to page that needs something
> preped/setup then simply make sure you go through the appropriate
> DispatchAction prep method. Are there more flexible solutions out
> there? I'm sure there are. The above has been working fine for me though.
I would suggest adding that approach to the Wiki page! If it is working
that well for you, then it is certainly a relevant addition that may
help others.
It's probably not worth debating how one solution compares to another
because they all have their benefits and problems, but we all seem to be
agreeing that the optimal solution hasn't been put forward yet (remember
we're ignoring 1.3 and chain in this discussion). Also how big a
problem it actually is doesn't seem very important. It *is* clearly
faced by people to one degree or another, so posting various approaches
is a worthwild exercise in my opinion.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multiple ActionForms per ActionMapping
Posted by Dakota Jack <da...@gmail.com>.
When you look at a line of such cases, Rick, the problems add up.
Suppose you have a workflow of five pages:
page1 --> page2 --> page3 --> page4 --> page5
With the suggestion, you have five ActionForms, each tightly knit to
the pages and four actions.
page1 ActionForm1 Action1 --> page2 ActionForm2 Action2 --> page3
ActionForm3 Action3 --> page4 ActionForm4 Action4 --> page5
ActionForm5.
If you use a setup Action, you end up with
page1 ActionForm1 Action1 --> SetupAction2 ActionForm2 --> page2
Action2 --> SetupAction3 ActionForm3 -- page3 Action3 --> SetupAction4
ActionForm4 --> page4 Action4 --> SetupAction5 ActionForm5 --> page5
Action5.
Or you can use a monolithic ActionForm which covers the whole process:
page1 ActionForm1 Action1 --> page2 ActionForm1 Action2 --> page3
ActionForm1 Action3 --> page4 ActionForm1 Action4 --> page5
ActionForm1 Action5
Or you can use a monolithic page, etc.
In any event, I really don't see why people would not vastly prefer
the first setup. Just watch the lists and see how many issues resolve
into the trouble created here.
Jack
On Thu, 17 Mar 2005 22:00:26 -0500, Rick Reumann <st...@reumann.net> wrote:
> Frank W. Zammetti wrote the following on 3/17/2005 6:35 PM:
>
> > * I could "chain" Actions, i.e., forward to an Action instead of
> > immediately to the second pages' JSP, that is specifically designed to
> > get the values for that dropdown. Aside from the overhead of the extra
> > pass through the entire framework, it's a kludge anyway.
>
> I totally disagree that the above is a hack or kludge.
>
> First off, if you are using Struts you are always going through a
> controller, even if the basic FowardAction, so even when you say you are
> going "immediately" to another page you are still going through a
> controller.
>
> Second, the next page obviously has a form on it and that form will
> submit to an Action. So why is it such a big deal to have a setUp
> dispatch method there? And once you have that setUp method in there
> (which sets up your drop downs), it's just a matter of fowarding to this
> action and giving it the dispatch setUp parameter.
>
> I'm actually suprised you guys think this is such a big deal. The
> situation C that I brought up a couple posts back is much more of
> annoying problem and I thought that's what you were talking about.
>
> Sure you can make it more eloquent by using the chain stuff, or even the
> cool idea you came up with Frank, to setup what you need, but I wouldn't
> see this is a "big problem" as Jack put it. Actually, Jack, your
> initial post mentions:
>
> "I am surprised if it is not an important point for all of us."
>
> I for one, don't see this as that important in grand scheme of things. I
> think the apps I'm stuck to work on are pretty complex, but even the
> most basic struts developer can follow the concepts very easily:
>
> Pages submit to DispatchAction methods. Most actions have a prep method
> (setUp concept) used to set up the request (or the form) with any
> necessary items. If you need to get to page that needs something
> preped/setup then simply make sure you go through the appropriate
> DispatchAction prep method. Are there more flexible solutions out
> there? I'm sure there are. The above has been working fine for me though.
>
> --
> Rick
>
> ---------------------------------------------------------------------
> 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: Multiple ActionForms per ActionMapping
Posted by Rick Reumann <st...@reumann.net>.
Frank W. Zammetti wrote the following on 3/17/2005 6:35 PM:
> * I could "chain" Actions, i.e., forward to an Action instead of
> immediately to the second pages' JSP, that is specifically designed to
> get the values for that dropdown. Aside from the overhead of the extra
> pass through the entire framework, it's a kludge anyway.
I totally disagree that the above is a hack or kludge.
First off, if you are using Struts you are always going through a
controller, even if the basic FowardAction, so even when you say you are
going "immediately" to another page you are still going through a
controller.
Second, the next page obviously has a form on it and that form will
submit to an Action. So why is it such a big deal to have a setUp
dispatch method there? And once you have that setUp method in there
(which sets up your drop downs), it's just a matter of fowarding to this
action and giving it the dispatch setUp parameter.
I'm actually suprised you guys think this is such a big deal. The
situation C that I brought up a couple posts back is much more of
annoying problem and I thought that's what you were talking about.
Sure you can make it more eloquent by using the chain stuff, or even the
cool idea you came up with Frank, to setup what you need, but I wouldn't
see this is a "big problem" as Jack put it. Actually, Jack, your
initial post mentions:
"I am surprised if it is not an important point for all of us."
I for one, don't see this as that important in grand scheme of things. I
think the apps I'm stuck to work on are pretty complex, but even the
most basic struts developer can follow the concepts very easily:
Pages submit to DispatchAction methods. Most actions have a prep method
(setUp concept) used to set up the request (or the form) with any
necessary items. If you need to get to page that needs something
preped/setup then simply make sure you go through the appropriate
DispatchAction prep method. Are there more flexible solutions out
there? I'm sure there are. The above has been working fine for me though.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multiple ActionForms per ActionMapping
Posted by Dakota Jack <da...@gmail.com>.
That's it! Frank nails it again! ///;-)
On Thu, 17 Mar 2005 18:35:52 -0500, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> Let me try and explain...
>
> Let's say I have a wizard-like interface to my site... One the first
> page I enter some values, let's say First Name, Last Name and Social
> Security Number. I click Next.
>
> Now, the next page that will be shown will prompt me to enter an address
> for the person I just entered. It's really independant of what I did on
> the first page (I'm just collecting information until, presumably, some
> save process at the end occurs). Let's say one of the fields is a
> dropdown of countries. I don't want to hardcode this into my page, and
> rightly you would agree I think :) So, I need some server process to
> read from a database maybe and return the values for the dropdown.
>
> Now, what happens when we click Next from the first page? The usual...
> an ActionForm is instantiated and populated and sent to some Action. I
> do whatever it is I do there, and I return a forward to send me to the
> second page.
>
> Here's where the problem comes in... At what point in this process do I
> get that list of values for the country dropdown on the second page?
>
> There are plenty of alternatives...
>
> * I could read from the database in the first Action (delegate to some
> business class hopefully!) and stick it directly in Request. But that
> breaks isolation between the pages. The Action associated with one page
> should not set up for another.
>
> * I could "chain" Actions, i.e., forward to an Action instead of
> immediately to the second pages' JSP, that is specifically designed to
> get the values for that dropdown. Aside from the overhead of the extra
> pass through the entire framework, it's a kludge anyway.
>
> * I could instantiate the second "setup" Action at the end of the first
> Actions' execute(), and call the seconds' execute() manually, which
> presumably gets the list and sticks it in request. I've used this
> solution the most myself, but it too suffers from the lack of isolation
> between Actions.
>
> * I suppose you could read the values from the database in the JSP, but
> you'd be shot on sight and I'd be the one yelling FIRE! :)
>
> * You could use my setupItems. But, that is something you have to do
> yourself and it will almost certainly result in an incompatibility with
> future versions of Struts.
>
> There are I'm sure other answers too.
>
> But all of them, well, not my setupItems! :) are ugly hacks.
>
> I have to agree with Jack that this is a very common use case (the most
> common? That might be debatable, but certainly very common).
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> Rick Reumann wrote:
> > Dakota Jack wrote the following on 3/17/2005 4:20 PM:
> >
> >> I am with Joe on this one. This situation is, at least for me, the
> >> most common situation I face. Every page except the welcome page has
> >> input for me.
> >
> >
> > Sorry, I'm not bringing this to the dev list because I'm first just
> > trying to understand what exactly is the 'common situation'. I don't
> > think your wiki post explains the problem very well (granted I'm dense,
> > so bare with me.) The wiki states:
> >
> > "The most common use case that I know of is when we go from one page to
> > another page on the browser, sending the server certain request values
> > from the first page and getting from the server certain response values
> > on the second page. Most pages have both input data (setup) and output
> > data (request name/value pairs).
> >
> > I presume that we are using Struts, so the first page and the second
> > page will each have different <html:form> values."
> >
> >
> > If I'm understanding you correctly, the only time I find the above is
> > slighlty problematic is when what needs to be populated on "Page 2" is
> > directly dictated by what was submited on "Page 1." If this is the
> > case, I certainly wouldn't say that is the most common problem in
> > relation to form submits.
> >
> > I tend to think the order of most common scenarios (in relation to form
> > submits) would be...
> >
> > 1) User submits a form. Result page needs to display some sort of
> > results based on the form info submitted. This could be a simple
> > cofirmation message or maybe a results page with a list of employees,
> > car types, or some financial results. Typically this page is also
> > interactive in the sense you could often click on an employee or car
> > name to get more info. [I'd hopefully be correct in assuming this first
> > scenario is unaffected by the problem you are proposing?]
> >
> > 2) User submits form. After processing the data, the user needs to be
> > brought to another form where he/she will enter in more information.
> > This scenario falls into three basic types in how the two forms are
> > related...
> >
> > o A) Form 2 (page 2) does not need to be prepopulated with anything
> > special. The simple default values in the ActionForm backing the page
> > are good enough.
> > - in this case after form 1 submits it's as simple as doing a
> > typical forward to the jsp holding form 2
> >
> > o B) Page 2 needs to have some prepopulation take place.
> > - This is a case for when I think forwarding to another Action is
> > just fine. So when form1 submitted, my "success" foward would simply
> > equate to the Action mapping needed for page 2:
> >
> > <forward name="success" path="/carStuff.do?dispatch=setUp"/>
> >
> > o C) The form on Page 2 needs to be populated with data that is
> > DEPENDENT on what the user submited on the form on page 1. [I believe
> > this is the case you and Joe are most concerned with?] The problem is
> > that you now need to create an instance of the ActionForm that you need
> > on page 2 and populate it in the Action that form 1 submits to OR, what
> > I'd probably do, is... after I'm done processing what I need in my first
> > Action, I'd stuff the values that I needed in the next action back into
> > the request and foward to my next action like in step B above. Of course
> > I might have a different dispatch method for this for when I know I'd be
> > coming from this type of scenario. Maybe something like processFromXXX
> > or something like that. I think the difference in the approaches is that
> > you'd want to leave the 1st Action and go right to the next page (with a
> > new form) whereas I think it's more clean to foward to the approriate
> > action to take care of any prepopulation (even if based on params from
> > an earlier request). With this later approach you don't need to worry
> > aobut creating the correct ActionForm instance.
> >
> >
> > *I guess my question is what scenario are you guys mentioning that is
> > common for the cause of this concern? I'm guessing it is step 2.C above?
> > With the preponderance of possible struts questions that come along this
> > certainly is not 'that' common. I don't see that many applications where
> > every page is a form and each form's population of fields is that
> > intricately tied to what was submitted on the previous form. (Exception
> > of course is wizard based applications - like steps to filling out
> > online taxes, which in that case, I think one ActionForm across requests
> > is the cleanest approach).
> >
> > I'm not trying to be a pain, but I'm sure I'm not the only one that is
> > slightly confused by the problem statement that you are posing on the
> > wiki page.
> >
> >
> >
> >
> > And, I have to redirect the welcome page because I need
> >
> >> data there too. I bet if you looked at the posts to the users list
> >> seriatim you would find that a very surprising percentage of posts
> >> would center on this problem. I know that it can be solved
> >> programmatically, Rick, but think that this is something the framework
> >> should do.
> >>
> >> I agree that ActionForms should be associated with page forms. That
> >> is why I think this should happen.
> >>
> >> Jack
> >>
> >> http://wiki.apache.org/struts/StrutsMultipleActionForms
> >>
> >>
> >> On Thu, 17 Mar 2005 15:05:28 -0600, Joe Germuska <Jo...@germuska.com>
> >> wrote:
> >>
> >>> I find this a quite common experience, and I just posted a response
> >>> to Jack on the dev list outlining the direction I intend to take to
> >>> provide a solution. Also, as noted on the dev list, now that Struts
> >>> 1.3 allows you to easily configure arbitrary String properties on
> >>> ActionMapping (ActionConfig) means that it should be relatively
> >>> straightforward to add properties like "responseform.name" and
> >>> "responseform.scope" and do whatever you want with them.
> >>>
> >>> I'm afraid that in the current Struts model, there are still quite a
> >>> few things to juggle to get an ActionForm instance. At the bare
> >>> minimum, you need an HttpServletRequest (and from it, a ModuleConfig
> >>> and possibly the session) and two Strings.
> >>>
> >>> I think it would be nice to make it very clear how to get an instance
> >>> with out having to juggle all of these. It would be possible, for
> >>> instance, to add a method to ActionContext (which encapsulates the
> >>> request scope, the session scope, and the module config) which would
> >>> take two String arguments and return an ActionForm. I think some
> >>> would object to putting that much behavior in ActionContext, so an
> >>> alternative would be to pick a Utils class (or maybe the
> >>> ModuleConfig) and pass it the ActionContext and two strings.
> >>>
> >>> If you're interested in the issue, though, let's continue the
> >>> discussion on "dev" (thread subject: "ActionConfig property map and
> >>> form setup strategies (Re: POJO Actions and the ActionCommand
> >>> interface)")
> >>>
> >>> Joe
> >>>
> >>> At 2:50 PM -0500 3/17/05, Rick Reumann wrote:
> >>>
> >>>> Rick Reumann wrote the following on 3/17/2005 2:29 PM:
> >>>>
> >>>>
> >>>>> Convincing me that 'more' ActionForms are a good thing is going to
> >>>>> be a difficult task, but restate or post your summary propostion
> >>>>> and I'll 'attempt' to look at it without any preconceived notions
> >>>>> that you might be crazy:)
> >>>>
> >>>>
> >>>> Jack, I saw your post here on the dev list, and I believe I know the
> >>>> problem you are talking about. Yes, I have run into the annoying
> >>>> situation where you have a new form you need to set for the
> >>>> resulting page you will be forwarded to. I'd argue though that this
> >>>> isn't "that" common of occurrence and when it does occur I don't
> >>>> find it that big of a deal to just manually instantiate the form
> >>>> that I'll need (in the first action) and stuff it into scope so it's
> >>>> ready for the ensuing jsp to use. (I could be wrong, though, in
> >>>> understanding the situation you are concerned with.)
> >>>
> >>>
> >>> --
> >>> Joe Germuska
> >>> Joe@Germuska.com
> >>> http://blog.germuska.com
> >>> "Narrow minds are weapons made for mass destruction" -The Ex
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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: Multiple ActionForms per ActionMapping
Posted by Leon Rosenberg <st...@anotheria.net>.
> * I could read from the database in the first Action
> (delegate to some business class hopefully!) and stick it
> directly in Request. But that breaks isolation between the
> pages. The Action associated with one page should not set up
> for another.
One thing I don't understand...
The actions and the jsps are already connected to each other by the use-case
and the requirement
that the second action/jsp depends on the first. The use case could even go
so far, that the
first action have to decide whether to show the second action at all
dependent on what the user entered
there, right (Like in do you want additional insurance contract when you buy
a car)?
Or it could decide whether to forward to action 2a or action 2b and
therefore influence the flow of events
in this use case.
What I don't understand is, why we should isolate two actions, which are
tied to each other by definition?
I think a wizard, and we are talking about wizards, as Rick explained in his
mail, which was much better phrased as mine,
is not only a collection of forms, but also the flow of control inbetween
the forms.
Why should I break this natural dependency?
Regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multiple ActionForms per ActionMapping
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Let me try and explain...
Let's say I have a wizard-like interface to my site... One the first
page I enter some values, let's say First Name, Last Name and Social
Security Number. I click Next.
Now, the next page that will be shown will prompt me to enter an address
for the person I just entered. It's really independant of what I did on
the first page (I'm just collecting information until, presumably, some
save process at the end occurs). Let's say one of the fields is a
dropdown of countries. I don't want to hardcode this into my page, and
rightly you would agree I think :) So, I need some server process to
read from a database maybe and return the values for the dropdown.
Now, what happens when we click Next from the first page? The usual...
an ActionForm is instantiated and populated and sent to some Action. I
do whatever it is I do there, and I return a forward to send me to the
second page.
Here's where the problem comes in... At what point in this process do I
get that list of values for the country dropdown on the second page?
There are plenty of alternatives...
* I could read from the database in the first Action (delegate to some
business class hopefully!) and stick it directly in Request. But that
breaks isolation between the pages. The Action associated with one page
should not set up for another.
* I could "chain" Actions, i.e., forward to an Action instead of
immediately to the second pages' JSP, that is specifically designed to
get the values for that dropdown. Aside from the overhead of the extra
pass through the entire framework, it's a kludge anyway.
* I could instantiate the second "setup" Action at the end of the first
Actions' execute(), and call the seconds' execute() manually, which
presumably gets the list and sticks it in request. I've used this
solution the most myself, but it too suffers from the lack of isolation
between Actions.
* I suppose you could read the values from the database in the JSP, but
you'd be shot on sight and I'd be the one yelling FIRE! :)
* You could use my setupItems. But, that is something you have to do
yourself and it will almost certainly result in an incompatibility with
future versions of Struts.
There are I'm sure other answers too.
But all of them, well, not my setupItems! :) are ugly hacks.
I have to agree with Jack that this is a very common use case (the most
common? That might be debatable, but certainly very common).
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Rick Reumann wrote:
> Dakota Jack wrote the following on 3/17/2005 4:20 PM:
>
>> I am with Joe on this one. This situation is, at least for me, the
>> most common situation I face. Every page except the welcome page has
>> input for me.
>
>
> Sorry, I'm not bringing this to the dev list because I'm first just
> trying to understand what exactly is the 'common situation'. I don't
> think your wiki post explains the problem very well (granted I'm dense,
> so bare with me.) The wiki states:
>
> "The most common use case that I know of is when we go from one page to
> another page on the browser, sending the server certain request values
> from the first page and getting from the server certain response values
> on the second page. Most pages have both input data (setup) and output
> data (request name/value pairs).
>
> I presume that we are using Struts, so the first page and the second
> page will each have different <html:form> values."
>
>
> If I'm understanding you correctly, the only time I find the above is
> slighlty problematic is when what needs to be populated on "Page 2" is
> directly dictated by what was submited on "Page 1." If this is the
> case, I certainly wouldn't say that is the most common problem in
> relation to form submits.
>
> I tend to think the order of most common scenarios (in relation to form
> submits) would be...
>
> 1) User submits a form. Result page needs to display some sort of
> results based on the form info submitted. This could be a simple
> cofirmation message or maybe a results page with a list of employees,
> car types, or some financial results. Typically this page is also
> interactive in the sense you could often click on an employee or car
> name to get more info. [I'd hopefully be correct in assuming this first
> scenario is unaffected by the problem you are proposing?]
>
> 2) User submits form. After processing the data, the user needs to be
> brought to another form where he/she will enter in more information.
> This scenario falls into three basic types in how the two forms are
> related...
>
> o A) Form 2 (page 2) does not need to be prepopulated with anything
> special. The simple default values in the ActionForm backing the page
> are good enough.
> - in this case after form 1 submits it's as simple as doing a
> typical forward to the jsp holding form 2
>
> o B) Page 2 needs to have some prepopulation take place.
> - This is a case for when I think forwarding to another Action is
> just fine. So when form1 submitted, my "success" foward would simply
> equate to the Action mapping needed for page 2:
>
> <forward name="success" path="/carStuff.do?dispatch=setUp"/>
>
> o C) The form on Page 2 needs to be populated with data that is
> DEPENDENT on what the user submited on the form on page 1. [I believe
> this is the case you and Joe are most concerned with?] The problem is
> that you now need to create an instance of the ActionForm that you need
> on page 2 and populate it in the Action that form 1 submits to OR, what
> I'd probably do, is... after I'm done processing what I need in my first
> Action, I'd stuff the values that I needed in the next action back into
> the request and foward to my next action like in step B above. Of course
> I might have a different dispatch method for this for when I know I'd be
> coming from this type of scenario. Maybe something like processFromXXX
> or something like that. I think the difference in the approaches is that
> you'd want to leave the 1st Action and go right to the next page (with a
> new form) whereas I think it's more clean to foward to the approriate
> action to take care of any prepopulation (even if based on params from
> an earlier request). With this later approach you don't need to worry
> aobut creating the correct ActionForm instance.
>
>
> *I guess my question is what scenario are you guys mentioning that is
> common for the cause of this concern? I'm guessing it is step 2.C above?
> With the preponderance of possible struts questions that come along this
> certainly is not 'that' common. I don't see that many applications where
> every page is a form and each form's population of fields is that
> intricately tied to what was submitted on the previous form. (Exception
> of course is wizard based applications - like steps to filling out
> online taxes, which in that case, I think one ActionForm across requests
> is the cleanest approach).
>
> I'm not trying to be a pain, but I'm sure I'm not the only one that is
> slightly confused by the problem statement that you are posing on the
> wiki page.
>
>
>
>
> And, I have to redirect the welcome page because I need
>
>> data there too. I bet if you looked at the posts to the users list
>> seriatim you would find that a very surprising percentage of posts
>> would center on this problem. I know that it can be solved
>> programmatically, Rick, but think that this is something the framework
>> should do.
>>
>> I agree that ActionForms should be associated with page forms. That
>> is why I think this should happen.
>>
>> Jack
>>
>> http://wiki.apache.org/struts/StrutsMultipleActionForms
>>
>>
>> On Thu, 17 Mar 2005 15:05:28 -0600, Joe Germuska <Jo...@germuska.com>
>> wrote:
>>
>>> I find this a quite common experience, and I just posted a response
>>> to Jack on the dev list outlining the direction I intend to take to
>>> provide a solution. Also, as noted on the dev list, now that Struts
>>> 1.3 allows you to easily configure arbitrary String properties on
>>> ActionMapping (ActionConfig) means that it should be relatively
>>> straightforward to add properties like "responseform.name" and
>>> "responseform.scope" and do whatever you want with them.
>>>
>>> I'm afraid that in the current Struts model, there are still quite a
>>> few things to juggle to get an ActionForm instance. At the bare
>>> minimum, you need an HttpServletRequest (and from it, a ModuleConfig
>>> and possibly the session) and two Strings.
>>>
>>> I think it would be nice to make it very clear how to get an instance
>>> with out having to juggle all of these. It would be possible, for
>>> instance, to add a method to ActionContext (which encapsulates the
>>> request scope, the session scope, and the module config) which would
>>> take two String arguments and return an ActionForm. I think some
>>> would object to putting that much behavior in ActionContext, so an
>>> alternative would be to pick a Utils class (or maybe the
>>> ModuleConfig) and pass it the ActionContext and two strings.
>>>
>>> If you're interested in the issue, though, let's continue the
>>> discussion on "dev" (thread subject: "ActionConfig property map and
>>> form setup strategies (Re: POJO Actions and the ActionCommand
>>> interface)")
>>>
>>> Joe
>>>
>>> At 2:50 PM -0500 3/17/05, Rick Reumann wrote:
>>>
>>>> Rick Reumann wrote the following on 3/17/2005 2:29 PM:
>>>>
>>>>
>>>>> Convincing me that 'more' ActionForms are a good thing is going to
>>>>> be a difficult task, but restate or post your summary propostion
>>>>> and I'll 'attempt' to look at it without any preconceived notions
>>>>> that you might be crazy:)
>>>>
>>>>
>>>> Jack, I saw your post here on the dev list, and I believe I know the
>>>> problem you are talking about. Yes, I have run into the annoying
>>>> situation where you have a new form you need to set for the
>>>> resulting page you will be forwarded to. I'd argue though that this
>>>> isn't "that" common of occurrence and when it does occur I don't
>>>> find it that big of a deal to just manually instantiate the form
>>>> that I'll need (in the first action) and stuff it into scope so it's
>>>> ready for the ensuing jsp to use. (I could be wrong, though, in
>>>> understanding the situation you are concerned with.)
>>>
>>>
>>> --
>>> Joe Germuska
>>> Joe@Germuska.com
>>> http://blog.germuska.com
>>> "Narrow minds are weapons made for mass destruction" -The Ex
>>>
>>> ---------------------------------------------------------------------
>>> 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: Multiple ActionForms per ActionMapping
Posted by Rick Reumann <st...@reumann.net>.
Dakota Jack wrote the following on 3/17/2005 4:20 PM:
> I am with Joe on this one. This situation is, at least for me, the
> most common situation I face. Every page except the welcome page has
> input for me.
Sorry, I'm not bringing this to the dev list because I'm first just
trying to understand what exactly is the 'common situation'. I don't
think your wiki post explains the problem very well (granted I'm dense,
so bare with me.) The wiki states:
"The most common use case that I know of is when we go from one page to
another page on the browser, sending the server certain request values
from the first page and getting from the server certain response values
on the second page. Most pages have both input data (setup) and output
data (request name/value pairs).
I presume that we are using Struts, so the first page and the second
page will each have different <html:form> values."
If I'm understanding you correctly, the only time I find the above is
slighlty problematic is when what needs to be populated on "Page 2" is
directly dictated by what was submited on "Page 1." If this is the
case, I certainly wouldn't say that is the most common problem in
relation to form submits.
I tend to think the order of most common scenarios (in relation to form
submits) would be...
1) User submits a form. Result page needs to display some sort of
results based on the form info submitted. This could be a simple
cofirmation message or maybe a results page with a list of employees,
car types, or some financial results. Typically this page is also
interactive in the sense you could often click on an employee or car
name to get more info. [I'd hopefully be correct in assuming this first
scenario is unaffected by the problem you are proposing?]
2) User submits form. After processing the data, the user needs to be
brought to another form where he/she will enter in more information.
This scenario falls into three basic types in how the two forms are
related...
o A) Form 2 (page 2) does not need to be prepopulated with anything
special. The simple default values in the ActionForm backing the page
are good enough.
- in this case after form 1 submits it's as simple as doing a
typical forward to the jsp holding form 2
o B) Page 2 needs to have some prepopulation take place.
- This is a case for when I think forwarding to another Action is
just fine. So when form1 submitted, my "success" foward would simply
equate to the Action mapping needed for page 2:
<forward name="success" path="/carStuff.do?dispatch=setUp"/>
o C) The form on Page 2 needs to be populated with data that is
DEPENDENT on what the user submited on the form on page 1. [I believe
this is the case you and Joe are most concerned with?] The problem is
that you now need to create an instance of the ActionForm that you need
on page 2 and populate it in the Action that form 1 submits to OR, what
I'd probably do, is... after I'm done processing what I need in my first
Action, I'd stuff the values that I needed in the next action back into
the request and foward to my next action like in step B above. Of course
I might have a different dispatch method for this for when I know I'd be
coming from this type of scenario. Maybe something like processFromXXX
or something like that. I think the difference in the approaches is that
you'd want to leave the 1st Action and go right to the next page (with a
new form) whereas I think it's more clean to foward to the approriate
action to take care of any prepopulation (even if based on params from
an earlier request). With this later approach you don't need to worry
aobut creating the correct ActionForm instance.
*I guess my question is what scenario are you guys mentioning that is
common for the cause of this concern? I'm guessing it is step 2.C above?
With the preponderance of possible struts questions that come along this
certainly is not 'that' common. I don't see that many applications where
every page is a form and each form's population of fields is that
intricately tied to what was submitted on the previous form. (Exception
of course is wizard based applications - like steps to filling out
online taxes, which in that case, I think one ActionForm across requests
is the cleanest approach).
I'm not trying to be a pain, but I'm sure I'm not the only one that is
slightly confused by the problem statement that you are posing on the
wiki page.
And, I have to redirect the welcome page because I need
> data there too. I bet if you looked at the posts to the users list
> seriatim you would find that a very surprising percentage of posts
> would center on this problem. I know that it can be solved
> programmatically, Rick, but think that this is something the framework
> should do.
>
> I agree that ActionForms should be associated with page forms. That
> is why I think this should happen.
>
> Jack
>
> http://wiki.apache.org/struts/StrutsMultipleActionForms
>
>
> On Thu, 17 Mar 2005 15:05:28 -0600, Joe Germuska <Jo...@germuska.com> wrote:
>
>>I find this a quite common experience, and I just posted a response
>>to Jack on the dev list outlining the direction I intend to take to
>>provide a solution. Also, as noted on the dev list, now that Struts
>>1.3 allows you to easily configure arbitrary String properties on
>>ActionMapping (ActionConfig) means that it should be relatively
>>straightforward to add properties like "responseform.name" and
>>"responseform.scope" and do whatever you want with them.
>>
>>I'm afraid that in the current Struts model, there are still quite a
>>few things to juggle to get an ActionForm instance. At the bare
>>minimum, you need an HttpServletRequest (and from it, a ModuleConfig
>>and possibly the session) and two Strings.
>>
>>I think it would be nice to make it very clear how to get an instance
>>with out having to juggle all of these. It would be possible, for
>>instance, to add a method to ActionContext (which encapsulates the
>>request scope, the session scope, and the module config) which would
>>take two String arguments and return an ActionForm. I think some
>>would object to putting that much behavior in ActionContext, so an
>>alternative would be to pick a Utils class (or maybe the
>>ModuleConfig) and pass it the ActionContext and two strings.
>>
>>If you're interested in the issue, though, let's continue the
>>discussion on "dev" (thread subject: "ActionConfig property map and
>>form setup strategies (Re: POJO Actions and the ActionCommand
>>interface)")
>>
>>Joe
>>
>>At 2:50 PM -0500 3/17/05, Rick Reumann wrote:
>>
>>>Rick Reumann wrote the following on 3/17/2005 2:29 PM:
>>>
>>>
>>>>Convincing me that 'more' ActionForms are a good thing is going to
>>>>be a difficult task, but restate or post your summary propostion
>>>>and I'll 'attempt' to look at it without any preconceived notions
>>>>that you might be crazy:)
>>>
>>>Jack, I saw your post here on the dev list, and I believe I know the
>>>problem you are talking about. Yes, I have run into the annoying
>>>situation where you have a new form you need to set for the
>>>resulting page you will be forwarded to. I'd argue though that this
>>>isn't "that" common of occurrence and when it does occur I don't
>>>find it that big of a deal to just manually instantiate the form
>>>that I'll need (in the first action) and stuff it into scope so it's
>>>ready for the ensuing jsp to use. (I could be wrong, though, in
>>>understanding the situation you are concerned with.)
>>
>>--
>>Joe Germuska
>>Joe@Germuska.com
>>http://blog.germuska.com
>>"Narrow minds are weapons made for mass destruction" -The Ex
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
>
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multiple ActionForms per ActionMapping
Posted by Dakota Jack <da...@gmail.com>.
I am with Joe on this one. This situation is, at least for me, the
most common situation I face. Every page except the welcome page has
input for me. And, I have to redirect the welcome page because I need
data there too. I bet if you looked at the posts to the users list
seriatim you would find that a very surprising percentage of posts
would center on this problem. I know that it can be solved
programmatically, Rick, but think that this is something the framework
should do.
I agree that ActionForms should be associated with page forms. That
is why I think this should happen.
Jack
http://wiki.apache.org/struts/StrutsMultipleActionForms
On Thu, 17 Mar 2005 15:05:28 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> I find this a quite common experience, and I just posted a response
> to Jack on the dev list outlining the direction I intend to take to
> provide a solution. Also, as noted on the dev list, now that Struts
> 1.3 allows you to easily configure arbitrary String properties on
> ActionMapping (ActionConfig) means that it should be relatively
> straightforward to add properties like "responseform.name" and
> "responseform.scope" and do whatever you want with them.
>
> I'm afraid that in the current Struts model, there are still quite a
> few things to juggle to get an ActionForm instance. At the bare
> minimum, you need an HttpServletRequest (and from it, a ModuleConfig
> and possibly the session) and two Strings.
>
> I think it would be nice to make it very clear how to get an instance
> with out having to juggle all of these. It would be possible, for
> instance, to add a method to ActionContext (which encapsulates the
> request scope, the session scope, and the module config) which would
> take two String arguments and return an ActionForm. I think some
> would object to putting that much behavior in ActionContext, so an
> alternative would be to pick a Utils class (or maybe the
> ModuleConfig) and pass it the ActionContext and two strings.
>
> If you're interested in the issue, though, let's continue the
> discussion on "dev" (thread subject: "ActionConfig property map and
> form setup strategies (Re: POJO Actions and the ActionCommand
> interface)")
>
> Joe
>
> At 2:50 PM -0500 3/17/05, Rick Reumann wrote:
> >Rick Reumann wrote the following on 3/17/2005 2:29 PM:
> >
> >>Convincing me that 'more' ActionForms are a good thing is going to
> >>be a difficult task, but restate or post your summary propostion
> >>and I'll 'attempt' to look at it without any preconceived notions
> >>that you might be crazy:)
> >
> >Jack, I saw your post here on the dev list, and I believe I know the
> >problem you are talking about. Yes, I have run into the annoying
> >situation where you have a new form you need to set for the
> >resulting page you will be forwarded to. I'd argue though that this
> >isn't "that" common of occurrence and when it does occur I don't
> >find it that big of a deal to just manually instantiate the form
> >that I'll need (in the first action) and stuff it into scope so it's
> >ready for the ensuing jsp to use. (I could be wrong, though, in
> >understanding the situation you are concerned with.)
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
> ---------------------------------------------------------------------
> 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: Multiple ActionForms per ActionMapping
Posted by Joe Germuska <Jo...@Germuska.com>.
I find this a quite common experience, and I just posted a response
to Jack on the dev list outlining the direction I intend to take to
provide a solution. Also, as noted on the dev list, now that Struts
1.3 allows you to easily configure arbitrary String properties on
ActionMapping (ActionConfig) means that it should be relatively
straightforward to add properties like "responseform.name" and
"responseform.scope" and do whatever you want with them.
I'm afraid that in the current Struts model, there are still quite a
few things to juggle to get an ActionForm instance. At the bare
minimum, you need an HttpServletRequest (and from it, a ModuleConfig
and possibly the session) and two Strings.
I think it would be nice to make it very clear how to get an instance
with out having to juggle all of these. It would be possible, for
instance, to add a method to ActionContext (which encapsulates the
request scope, the session scope, and the module config) which would
take two String arguments and return an ActionForm. I think some
would object to putting that much behavior in ActionContext, so an
alternative would be to pick a Utils class (or maybe the
ModuleConfig) and pass it the ActionContext and two strings.
If you're interested in the issue, though, let's continue the
discussion on "dev" (thread subject: "ActionConfig property map and
form setup strategies (Re: POJO Actions and the ActionCommand
interface)")
Joe
At 2:50 PM -0500 3/17/05, Rick Reumann wrote:
>Rick Reumann wrote the following on 3/17/2005 2:29 PM:
>
>>Convincing me that 'more' ActionForms are a good thing is going to
>>be a difficult task, but restate or post your summary propostion
>>and I'll 'attempt' to look at it without any preconceived notions
>>that you might be crazy:)
>
>Jack, I saw your post here on the dev list, and I believe I know the
>problem you are talking about. Yes, I have run into the annoying
>situation where you have a new form you need to set for the
>resulting page you will be forwarded to. I'd argue though that this
>isn't "that" common of occurrence and when it does occur I don't
>find it that big of a deal to just manually instantiate the form
>that I'll need (in the first action) and stuff it into scope so it's
>ready for the ensuing jsp to use. (I could be wrong, though, in
>understanding the situation you are concerned with.)
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multiple ActionForms per ActionMapping
Posted by Rick Reumann <st...@reumann.net>.
Rick Reumann wrote the following on 3/17/2005 2:29 PM:
> Convincing me that 'more' ActionForms are a good thing is going to be a
> difficult task, but restate or post your summary propostion and I'll
> 'attempt' to look at it without any preconceived notions that you might
> be crazy:)
Jack, I saw your post here on the dev list, and I believe I know the
problem you are talking about. Yes, I have run into the annoying
situation where you have a new form you need to set for the resulting
page you will be forwarded to. I'd argue though that this isn't "that"
common of occurrence and when it does occur I don't find it that big of
a deal to just manually instantiate the form that I'll need (in the
first action) and stuff it into scope so it's ready for the ensuing jsp
to use. (I could be wrong, though, in understanding the situation you
are concerned with.)
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multiple ActionForms per ActionMapping
Posted by Rick Reumann <st...@reumann.net>.
Do you have a summary of your view? and preferably a very simple flow
chart or example? There have been a trillion posts lately and haven't
had time to sift through them all.
All I can say is the concept of the ActionForm was initially proposed so
that the user can be given back exactly what he entered when validation
failed. I certainly don't want more Action forms. Because I have to
develop code in a situation where I have tons of nested properties, I
could actually code without any ActionForms (since typically my
ActionForm would only hold one bean which holds a collection of other
beans each with their own collections, etc etc. It's just the nature of
the beast of the objects I have to work with coming from the backend and
for the types of data entry that needs to be done).
Convincing me that 'more' ActionForms are a good thing is going to be a
difficult task, but restate or post your summary propostion and I'll
'attempt' to look at it without any preconceived notions that you might
be crazy:)
Dakota Jack wrote the following on 3/17/2005 2:04 PM:
> I have put forward a very basis description of what I take to be a
> compelling case for multiple ActionForms for Actions. I encourage any
> of you to hammer what I say there, add to the facts, straighten out
> the logic, etc., because for me this is an very important point. I am
> surprised if it is not an important point for all of us. Surprise me,
> if it is not.
>
> I am ready to see that I am missing something, because Ted thinks
> otherwise and he usually is the epitome of good common sense in
> coding. I don't see it here and am open to being taught something
> new.
>
> Jack
>
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org