Re: Multiple ActionForms per ActionMapping
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
On Sat, 19 Mar 2005 10:19:31 +0530, Vamsee Kanakala <[EMAIL PROTECTED]> 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. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
This is probably obvious, but you can choose to validate other than in the ActionForm, which I do, and not validate in the Action as well, which I also do. I leave validation to a validation application which sits between the business logic and the view for me. Jack On Fri, 18 Mar 2005 11:33:08 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > Hijack alert! > > At 11:09 AM -0500 3/18/05, Rick Reumann wrote: > >Well, actually I like to have my own validate() method in each of my > >Dispatch Actions. I don't like having the framework call validate > >for me. One of the main reason is that if I'm in my action and I > >manually call my own action's validate() method then, if validation > >fails, I can make sure my prep method is always called. I wrote > >about this here http://reumann.net/struts/articles/request_lists.jsp > >and at the end I give an example of what I like to do. (I'm curious, > >in that approach you came up with, if validation were to fail, would > >the extra 'setup' that you added to the action mapping be called? If > >so, that would be very nice! if not then I'd still end up having to > >use my prep/set up method). > > This is one of the reasons I like a design which associates prep > logic with the destination (forward) instead of the action/request. > > If that's the only reason you validate in your actions instead of in > the framework, maybe you'd like it too... > > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
Hijack alert! At 11:09 AM -0500 3/18/05, Rick Reumann wrote: Well, actually I like to have my own validate() method in each of my Dispatch Actions. I don't like having the framework call validate for me. One of the main reason is that if I'm in my action and I manually call my own action's validate() method then, if validation fails, I can make sure my prep method is always called. I wrote about this here http://reumann.net/struts/articles/request_lists.jsp and at the end I give an example of what I like to do. (I'm curious, in that approach you came up with, if validation were to fail, would the extra 'setup' that you added to the action mapping be called? If so, that would be very nice! if not then I'd still end up having to use my prep/set up method). This is one of the reasons I like a design which associates prep logic with the destination (forward) instead of the action/request. If that's the only reason you validate in your actions instead of in the framework, maybe you'd like it too... Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
There are a "jillion" solutions, of course. I still think, and maybe I am stating it too much, that the solution should be framework and definitely should not be in a session object. I do think that application data should be handled and have suggested a StrutsState application in application scope. But, the screen data should be handled, I think, by a screen application of ActionForm or like VOs. I would separate validation from ActionForm, etc. On Fri, 18 Mar 2005 10:32:35 -0500, Rick Reumann <[EMAIL PROTECTED]> wrote: > Frank W. Zammetti wrote the following on 3/17/2005 10:23 PM: > > > Certainly I can see the reasoning behind that, but I would have to > > disagree. What if down the road I need to use one of those screens > > independant of that original flow? Isn't it just added complexity to > > have all the extra stuff in the ActionForm then? > > Ok, then how about using separate ActionForms and after each submits > copy the properties (BeanUtils) to a POJO that you are using in Session > scope to hold the values you finally need. This way you have the > flexible separate ActionForms but still have a Master record holding > what you need along each step. (Heck, you could even take the lazy way > out and make the master session object a Map so you wouldn't even have > to care about creating the pojo ahead of time.. although I still prefer > a nice POJO over a Map for stuff like this.) > > > A good example is the application I was talking about itself... The six > > screens are not simple in and of themselves, there is quite a bit of > > complexity to the ActionForms for each, in terms of how many fields > > there certainy. If I combined them all it would be a very unwieldly > > beast to maintain (I'd have to look, but I can imagine it being close to > > 2,000 line of code without much trouble, perhaps more). > > Well, remember those 2000 lines of code are simply getters and setters > which are easily auto-generated. It's not really complex lines of code. > Really you are only maintaining field names. I do see your point though > about how it's nice having the ActionForms separate for a more resuable > approach. I'd opt for the option I mentioned above first, if you want to > keep the forms all separate. > > > In addition, how would you handle validation then? The validate() > > method is meant to apply to a single page (as is an ActionForm), > > Actually you can validate on an action mapping basis and not on the form > name, so only the fields you are interested in for the action mapping > get checked. > > -- > Rick > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Multiple ActionForms per ActionMapping
On Fri, March 18, 2005 11:46 am, Rick Reumann said: > Frank W. Zammetti wrote the following on 3/18/2005 11:34 AM: > >> At one point in time, and it might still stand, I don't >> know, I had the record in the Army for typing speed. I'm pretty quick >> :) > > I'll have to start calling you Radar:) Although I think he was probably > a pretty slow typist (faster than Klinger though I'm sure). I like the teddy bear :) Especially now that you can get those ones with the micro-bead thingies that are soft as hell. They rule! It's actually a funny story the day I set the record (76 WPM by the way... may not sound that high, but consider it was on an old teletype machine... I've broken 100 on numerous typing test programs throughout the years on a regular PC keyboard, some ridiculously high to the point where I believe the program had to be flawed!)... Being the Army, the seargents there were always busting our chops for random, senseless reasons. WHILE I WAS TYPING trying to set that record (and I don't know that this was any kind of official thing by the way, but the seargents seemed to keep track of it over the years) they were absolutely KILLING me because even to this day, I do not type with anything approaching a proper technique. They couldn't believe I could type AT ALL let alone as fast as I was. It's just years of typing (since I was about 7 as I recall) and just making up my own style. I don't think I should repeat most of the taunts they were using that day, but suffice it to say it's amazing I got THAT high :) What's more enjoyable now though than typing fast is the fact that, while I don't have remotely proper technique, I can in fact touch-type rather well. This annoys my wife to no end... she comes in to my home office, I'm hacking away at some code and she'll start talking to me... rather than stop what I'm doing I'll just continue typing, looking off to the side at her because of course I'd get yelled at if I didn't look at her while she was talking, but then she yells at me anyway because I'm "being a wise-ass" and coding while she's talking to me and not even looking at the keyboard! (she's not a bad typist herself, probably in the 30-40 WPM range, but she can't touch-type at all). (perhaps at this point this thread should be marked with a double OT!) > Rick Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
- Original Message - From: "Frank W. Zammetti" <[EMAIL PROTECTED]> Sent: Friday, March 18, 2005 4:34 PM > Good question about what happens with setupItems when validation fails... > I didn't think of that situation when I did it... Looking at the code, > NONE of the setupItems would be executed when a validation failure occurs. > I could move the code that does the mapping-level items up before the > validation is called and that would allow those to fire regardless. In > fact, I think that would be the only real answer because obviously the > forward-level items wouldn't come in to play when a validation failure > occurs. Good point for sure though. :) If you changed your RequestProcessor to call processSetupsPerform(request, forward) from the processForwardConfig() method rather than from the process method() - then Struts could be configured to use an "input forward" for error processing and the setupitems would get done. So in the struts-config you would have Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: Multiple ActionForms per ActionMapping
Frank W. Zammetti wrote the following on 3/18/2005 11:34 AM: At one point in time, and it might still stand, I don't know, I had the record in the Army for typing speed. I'm pretty quick :) I'll have to start calling you Radar:) Although I think he was probably a pretty slow typist (faster than Klinger though I'm sure). -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
On Fri, March 18, 2005 11:09 am, Rick Reumann said: > Ok, not going down that road..wacko:) > But seriously > though, you said you had about 2000 lines of code between your > ActionForms. How much time do you think it takes you type out all those > getters and setters for all those properties? Me persnoally? At one point in time, and it might still stand, I don't know, I had the record in the Army for typing speed. I'm pretty quick :) > No way, you can tell me > that autogeneration of those set/get methods wouldn't save you time and > we all know time==money. Granted. But I'm an old-school guys... I like knowing precisely where every piece of code in my application came from, how it works, and so forth. This means I like to write it all. I already have to give up a lot just by using Java, an app server, a framework, heck, even an operating system and BIOS and CPU microcode I suppose! :) Ok, NOW you can call me a wacko! :) More importantly though, I'd have to leave UltraEdit to get that capability, and that move I have found costs me more productivity than any I might be able to gain in another environment. My experience has been that IDEs (where auto-generation tends to be done) slows me down more than any gains it gives me. Clearly this is not typical, but it is true for me. (I should point out though that a class with pretty much nothing but getters and setters is NOT the case I would choose to argue against code generation in general :) This is a case I actually could live with it) > But I know, there won't be any convincing you > otherwise:) Hey, it wouldn't be me if I wasn't stubborn! :) Seriously though, when I feel passionately about something, I will argue until I'm blue in the face, but rest assured I will always listen, consider what others say and allow myself to be convinced when I believe warranted. I'm not closed-minded, but I am stubborn and perhaps slow to change sometimes :) > "An alternative approach is to use the action mapping path attribute. In > this case, you extend the ValidatorActionForm instead of the > ValidatorForm. The ValidatorActionForm uses the action element's path > attribute from the Struts configuration which should match the form > element's name attribute in the Validator configuration. > > Then a separate action mapping can be defined for each page in a > multi-page form, and the validation form can be associated with the > action rather than a page number (as shown in the example of a > multi-page form in the validator example)." Well, thank you for that. I have to admit this is new to me. I'll have to go do some reading. > Well, actually I like to have my own validate() method in each of my > Dispatch Actions. I don't like having the framework call validate for > me. One of the main reason is that if I'm in my action and I manually > call my own action's validate() method then, if validation fails, I can > make sure my prep method is always called. I wrote about this here > http://reumann.net/struts/articles/request_lists.jsp and at the end I > give an example of what I like to do. (I'm curious, in that approach you > came up with, if validation were to fail, would the extra 'setup' that > you added to the action mapping be called? If so, that would be very > nice! if not then I'd still end up having to use my prep/set up method). I was doing that same thing for a while too. It does make sense. The arguments against it of course get in to what is proper separation of the layers and all that jazz. Good question about what happens with setupItems when validation fails... I didn't think of that situation when I did it... Looking at the code, NONE of the setupItems would be executed when a validation failure occurs. I could move the code that does the mapping-level items up before the validation is called and that would allow those to fire regardless. In fact, I think that would be the only real answer because obviously the forward-level items wouldn't come in to play when a validation failure occurs. Good point for sure though. :) > Rick Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
Frank W. Zammetti wrote the following on 3/18/2005 10:42 AM: I'm not a believer in auto-generated code under any circumstance, even something as clearly mundane as getters and setters. Ok, not going down that road..wacko:) But seriously though, you said you had about 2000 lines of code between your ActionForms. How much time do you think it takes you type out all those getters and setters for all those properties? No way, you can tell me that autogeneration of those set/get methods wouldn't save you time and we all know time==money. But I know, there won't be any convincing you otherwise:) Actually you can validate on an action mapping basis and not on the form name, so only the fields you are interested in for the action mapping get checked. Can you explain that? Are you talking about using declarative validation? That is something I haven't used yet, but yes, I can see where that would remove the point I made. "An alternative approach is to use the action mapping path attribute. In this case, you extend the ValidatorActionForm instead of the ValidatorForm. The ValidatorActionForm uses the action element's path attribute from the Struts configuration which should match the form element's name attribute in the Validator configuration. Then a separate action mapping can be defined for each page in a multi-page form, and the validation form can be associated with the action rather than a page number (as shown in the example of a multi-page form in the validator example)." Certainly you would agree that if you choose to do validations in validate(), you would have the problem I mentioned, right? Or is there something here for me to learn? :) Well, actually I like to have my own validate() method in each of my Dispatch Actions. I don't like having the framework call validate for me. One of the main reason is that if I'm in my action and I manually call my own action's validate() method then, if validation fails, I can make sure my prep method is always called. I wrote about this here http://reumann.net/struts/articles/request_lists.jsp and at the end I give an example of what I like to do. (I'm curious, in that approach you came up with, if validation were to fail, would the extra 'setup' that you added to the action mapping be called? If so, that would be very nice! if not then I'd still end up having to use my prep/set up method). -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
On Fri, March 18, 2005 10:32 am, Rick Reumann said: > Ok, then how about using separate ActionForms and after each submits > copy the properties (BeanUtils) to a POJO that you are using in Session > scope to hold the values you finally need. This way you have the > flexible separate ActionForms but still have a Master record holding > what you need along each step. (Heck, you could even take the lazy way > out and make the master session object a Map so you wouldn't even have > to care about creating the pojo ahead of time.. although I still prefer > a nice POJO over a Map for stuff like this.) That's not a bad idea. Can't say I ever thought of it :) The one thing that would turn me off is the reflection involved. Reflection used to be a Very Bad Thing(tm), but over the years its become not much of a problem. Still though, I prefer to avoid it where possible to minimize scalability impacts (any extra overhead affects scalability of course). Still though, what you suggest is not at all bad! > Well, remember those 2000 lines of code are simply getters and setters > which are easily auto-generated. It's not really complex lines of code. > Really you are only maintaining field names. I do see your point though > about how it's nice having the ActionForms separate for a more resuable > approach. I'd opt for the option I mentioned above first, if you want to > keep the forms all separate. True. But even still, simply looking through more lines of code and finding what you need, regardless of how simple or complex the code is, is a pain the more code there is. I'm not a believer in auto-generated code under any circumstance, even something as clearly mundane as getters and setters. I know that isn't the majority position these days, and I understand the other side's opinion, but I'm not there yet myself, so that argument doesn't fly with me :) > Actually you can validate on an action mapping basis and not on the form > name, so only the fields you are interested in for the action mapping > get checked. Can you explain that? Are you talking about using declarative validation? That is something I haven't used yet, but yes, I can see where that would remove the point I made. Certainly you would agree that if you choose to do validations in validate(), you would have the problem I mentioned, right? Or is there something here for me to learn? :) > Rick Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
Frank W. Zammetti wrote the following on 3/17/2005 10:23 PM: Certainly I can see the reasoning behind that, but I would have to disagree. What if down the road I need to use one of those screens independant of that original flow? Isn't it just added complexity to have all the extra stuff in the ActionForm then? Ok, then how about using separate ActionForms and after each submits copy the properties (BeanUtils) to a POJO that you are using in Session scope to hold the values you finally need. This way you have the flexible separate ActionForms but still have a Master record holding what you need along each step. (Heck, you could even take the lazy way out and make the master session object a Map so you wouldn't even have to care about creating the pojo ahead of time.. although I still prefer a nice POJO over a Map for stuff like this.) A good example is the application I was talking about itself... The six screens are not simple in and of themselves, there is quite a bit of complexity to the ActionForms for each, in terms of how many fields there certainy. If I combined them all it would be a very unwieldly beast to maintain (I'd have to look, but I can imagine it being close to 2,000 line of code without much trouble, perhaps more). Well, remember those 2000 lines of code are simply getters and setters which are easily auto-generated. It's not really complex lines of code. Really you are only maintaining field names. I do see your point though about how it's nice having the ActionForms separate for a more resuable approach. I'd opt for the option I mentioned above first, if you want to keep the forms all separate. In addition, how would you handle validation then? The validate() method is meant to apply to a single page (as is an ActionForm), Actually you can validate on an action mapping basis and not on the form name, so only the fields you are interested in for the action mapping get checked. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
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 [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
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 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 <[EMAIL PROTECTED]> 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 > > 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 > > <[EMAIL PROTECTED]> 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 > >>><[EMAIL PROTECTED]> 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
Re: Multiple ActionForms per ActionMapping
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 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
Re: Multiple ActionForms per ActionMapping
The composable request processor has nothing to do with setting up the 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 <[EMAIL PROTECTED]> 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 > > <[EMAIL PROTECTED]> 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 (remembe
Re: Multiple ActionForms per ActionMapping
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubsc
Re: Multiple ActionForms per ActionMapping
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
Rick Reumann wrote: To me this is simple.. use one form and give is Session scope. Perfect for wizard stuff. You mentioned the sex screens are used to create a record in the DB, so one form to capture what you need makes sense. Certainly I can see the reasoning behind that, but I would have to disagree. What if down the road I need to use one of those screens independant of that original flow? Isn't it just added complexity to have all the extra stuff in the ActionForm then? A good example is the application I was talking about itself... The six screens are not simple in and of themselves, there is quite a bit of complexity to the ActionForms for each, in terms of how many fields there certainy. If I combined them all it would be a very unwieldly beast to maintain (I'd have to look, but I can imagine it being close to 2,000 line of code without much trouble, perhaps more). In addition, how would you handle validation then? The validate() method is meant to apply to a single page (as is an ActionForm), but if you have the fields for six screens in one ActionForm, even if they function as one logical screen, wouldn't you be introducing branch logic to your validate() code to ensure you do the validations appropriate for the screen being submitted at the time since its now the only such method for six screens? -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
If you use one form, you don't ahve to give it session scope, do you? On Thu, 17 Mar 2005 22:02:01 -0500, Rick Reumann <[EMAIL PROTECTED]> wrote: > Frank W. Zammetti wrote the following on 3/17/2005 7:01 PM: > > > I have an application where there are six screens. They are used to > > create a record in the database. When used this way, they do in fact > > represent a wizard-type flow. However, you can also recall the items > > from the database for editing, and the same screens are used, but, you > > now have the capability to jump between screens any way you wish. The > > same screens, and more importantly ACTIONS, are no longer used in the > > usual flow. If I had did what amounts to hardcoded that flow into the > > Actions by having one depent on another, I wouldn't be able (easily) to > > accomplish that. > > To me this is simple.. use one form and give is Session scope. Perfect > for wizard stuff. You mentioned the sex screens are used to create a > record in the DB, so one form to capture what you need makes sense. > > -- > Rick > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
Frank W. Zammetti wrote the following on 3/17/2005 8:57 PM: Argh... I love Baseball, have all my life, used to play from sunrise to sunset during the summers of my youth, but is there really no more pressing matters in this country for our elected representatives to be dealing with than steroid abuse in a sport?? roids, roids, good for your heart. The more you eat them the more you... oh wait those are beans. H are they stateless session beans? -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
Frank W. Zammetti wrote the following on 3/17/2005 7:01 PM: I have an application where there are six screens. They are used to create a record in the database. When used this way, they do in fact represent a wizard-type flow. However, you can also recall the items from the database for editing, and the same screens are used, but, you now have the capability to jump between screens any way you wish. The same screens, and more importantly ACTIONS, are no longer used in the usual flow. If I had did what amounts to hardcoded that flow into the Actions by having one depent on another, I wouldn't be able (easily) to accomplish that. To me this is simple.. use one form and give is Session scope. Perfect for wizard stuff. You mentioned the sex screens are used to create a record in the DB, so one form to capture what you need makes sense. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Multiple ActionForms per ActionMapping
In fact I did know that :) As far as the records go, I just can't stop thinking though that if the rules weren't in place when they were set, I just can't bring myself to have a problem with them. So the McGwires and Sosas of the world, in my mind, get a pass. The interesting case is Bonds though. But, even there, until there is actual evidence, being a big believer in the basic tenet of our legal system that says innocent until proven guilty, I can't have a problem with him either. Suspicions aren't enough to put an asterisk next to anything. I don't know... you raise a fair point about the need for oversight, but I still have a more negative impression of our congress spending time, effort and money on this than the myriad other things that are so much more important. Oh gee, did we veer off topic here?? ;) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Dakota Jack wrote: As a baseball nut, those records are sacrosanct to me and I just hate the idea of a record being the product of drugs. I am all for the oversight. This is especially so since baseball enjoins a monopoly because it is the officially recognized pastime. Did you know that? Jack On Thu, 17 Mar 2005 20:57:46 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: I frankly view Tiles as one of those things that *can* be nice in some cases, but more often than not just complicates matters. After all, it is just the JSP include mechanism on steroids, and as we all saw today, steroids are bad, mmmkay?? :) Argh... I love Baseball, have all my life, used to play from sunrise to sunset during the summers of my youth, but is there really no more pressing matters in this country for our elected representatives to be dealing with than steroid abuse in a sport?? I don't want my son to think it's OK to juice any more than any other parent, but come on, do we really need the expense of a senate hearing meant to do little else than embarass players and the time wasted from dealing with what are numerous clearly more important matters?? Sorry, had to vent :) Frank Leon Rosenberg wrote: An example... I have an application where there are six screens. They are used to create a record in the database. When used this way, they do in fact represent a wizard-type flow. However, you can also recall the items from the database for editing, and the same screens are used, but, you now have the capability to jump between screens any way you wish. The same screens, and more importantly ACTIONS, are no longer used in the usual flow. If I had did what amounts to hardcoded that flow into the Actions by having one depent on another, I wouldn't be able (easily) to accomplish that. You might say this is now a fringe case, and certainly it is less common than the example I gave before, but it still is not unusual (at least as far as my travels go :) ) Ok, makes sense. I have never had that sort of requirement/solution before, but it sounds feasible. To me, it sounds a bit like you'd need tiles :-), but the multi-form-processing-thingy would probably do it too :-) However, i'll wait till ist ready, see the result, and try to learn :-) Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: Multiple ActionForms per ActionMapping
As a baseball nut, those records are sacrosanct to me and I just hate the idea of a record being the product of drugs. I am all for the oversight. This is especially so since baseball enjoins a monopoly because it is the officially recognized pastime. Did you know that? Jack On Thu, 17 Mar 2005 20:57:46 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > I frankly view Tiles as one of those things that *can* be nice in some > cases, but more often than not just complicates matters. After all, it > is just the JSP include mechanism on steroids, and as we all saw today, > steroids are bad, mmmkay?? > > :) > > Argh... I love Baseball, have all my life, used to play from sunrise to > sunset during the summers of my youth, but is there really no more > pressing matters in this country for our elected representatives to be > dealing with than steroid abuse in a sport?? I don't want my son to > think it's OK to juice any more than any other parent, but come on, do > we really need the expense of a senate hearing meant to do little else > than embarass players and the time wasted from dealing with what are > numerous clearly more important matters?? > > Sorry, had to vent :) > > Frank > > Leon Rosenberg wrote: > >>An example... > >> > >>I have an application where there are six screens. They are > >>used to create a record in the database. When used this way, > >>they do in fact represent a wizard-type flow. However, you > >>can also recall the items from the database for editing, and > >>the same screens are used, but, you now have the capability > >>to jump between screens any way you wish. The same screens, > >>and more importantly ACTIONS, are no longer used in the usual > >>flow. If I had did what amounts to hardcoded that flow into > >>the Actions by having one depent on another, I wouldn't be > >>able (easily) to accomplish that. > >> > >>You might say this is now a fringe case, and certainly it is > >>less common than the example I gave before, but it still is > >>not unusual (at least as far as my travels go :) ) > >> > > > > > > Ok, makes sense. I have never had that sort of requirement/solution before, > > but it sounds feasible. > > To me, it sounds a bit like you'd need tiles :-), but the > > multi-form-processing-thingy would probably do it too :-) > > > > However, i'll wait till ist ready, see the result, and try to learn :-) > > > > Regards > > Leon > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > . > > > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
I frankly view Tiles as one of those things that *can* be nice in some cases, but more often than not just complicates matters. After all, it is just the JSP include mechanism on steroids, and as we all saw today, steroids are bad, mmmkay?? :) Argh... I love Baseball, have all my life, used to play from sunrise to sunset during the summers of my youth, but is there really no more pressing matters in this country for our elected representatives to be dealing with than steroid abuse in a sport?? I don't want my son to think it's OK to juice any more than any other parent, but come on, do we really need the expense of a senate hearing meant to do little else than embarass players and the time wasted from dealing with what are numerous clearly more important matters?? Sorry, had to vent :) Frank Leon Rosenberg wrote: An example... I have an application where there are six screens. They are used to create a record in the database. When used this way, they do in fact represent a wizard-type flow. However, you can also recall the items from the database for editing, and the same screens are used, but, you now have the capability to jump between screens any way you wish. The same screens, and more importantly ACTIONS, are no longer used in the usual flow. If I had did what amounts to hardcoded that flow into the Actions by having one depent on another, I wouldn't be able (easily) to accomplish that. You might say this is now a fringe case, and certainly it is less common than the example I gave before, but it still is not unusual (at least as far as my travels go :) ) Ok, makes sense. I have never had that sort of requirement/solution before, but it sounds feasible. To me, it sounds a bit like you'd need tiles :-), but the multi-form-processing-thingy would probably do it too :-) However, i'll wait till ist ready, see the result, and try to learn :-) Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
That's it! Frank nails it again! ///;-) On Thu, 17 Mar 2005 18:35:52 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> 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 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
Re: Multiple ActionForms per ActionMapping
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 <[EMAIL PROTECTED]> 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 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: > > > >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
Re: Multiple ActionForms per ActionMapping
> > An example... > > I have an application where there are six screens. They are > used to create a record in the database. When used this way, > they do in fact represent a wizard-type flow. However, you > can also recall the items from the database for editing, and > the same screens are used, but, you now have the capability > to jump between screens any way you wish. The same screens, > and more importantly ACTIONS, are no longer used in the usual > flow. If I had did what amounts to hardcoded that flow into > the Actions by having one depent on another, I wouldn't be > able (easily) to accomplish that. > > You might say this is now a fringe case, and certainly it is > less common than the example I gave before, but it still is > not unusual (at least as far as my travels go :) ) > Ok, makes sense. I have never had that sort of requirement/solution before, but it sounds feasible. To me, it sounds a bit like you'd need tiles :-), but the multi-form-processing-thingy would probably do it too :-) However, i'll wait till ist ready, see the result, and try to learn :-) Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
> > An example... > > I have an application where there are six screens. They are > used to create a record in the database. When used this way, > they do in fact represent a wizard-type flow. However, you > can also recall the items from the database for editing, and > the same screens are used, but, you now have the capability > to jump between screens any way you wish. The same screens, > and more importantly ACTIONS, are no longer used in the usual > flow. If I had did what amounts to hardcoded that flow into > the Actions by having one depent on another, I wouldn't be > able (easily) to accomplish that. > > You might say this is now a fringe case, and certainly it is > less common than the example I gave before, but it still is > not unusual (at least as far as my travels go :) ) > Ok, makes sense. I have never had that sort of requirement/solution before, but it sounds feasible. To me, it sounds a bit like you'd need tiles :-), but the multi-form-processing-thingy would probably do it too :-) However, i'll wait till ist ready, see the result, and try to learn :-) Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
What if what you have isn't truly a wizard but just a collection of screens that *generally* are used in a standard flow? An example... I have an application where there are six screens. They are used to create a record in the database. When used this way, they do in fact represent a wizard-type flow. However, you can also recall the items from the database for editing, and the same screens are used, but, you now have the capability to jump between screens any way you wish. The same screens, and more importantly ACTIONS, are no longer used in the usual flow. If I had did what amounts to hardcoded that flow into the Actions by having one depent on another, I wouldn't be able (easily) to accomplish that. You might say this is now a fringe case, and certainly it is less common than the example I gave before, but it still is not unusual (at least as far as my travels go :) ) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Leon Rosenberg 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
> * 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
> * 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
*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 [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
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 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 whe
Re: Multiple ActionForms per ActionMapping
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 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: 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 <[EMAIL PROTECTED]> wrote: I find this a quite commo
Re: Multiple ActionForms per ActionMapping
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 <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
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 [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple ActionForms per ActionMapping
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
