• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Link Only To Actions....

 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm using the practice of linking only to actions, but also trying to use the LookupDispatchMethod for routing into the correct action method.
My problem is that I cannot work out how to force processing into my screen preprocess method, ie as if the button (or action) had not been set yet when the form initially calls myaction.do.
Anyone out there know of a way to do this?
Dave
 
Ranch Hand
Posts: 374
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In your form bean, you can have a boolean property preProcessComplete. In validate(), check this field before doing validation...

Because validate returns true, processing will continue into your action.
In your action, again check preProcessComplete. If it is false, perform your pre-processing. As the last step, set preProcessComplete.

Another option is to link to a separate action preProcess.do that in turn forwards to the same JSP used as input for actualProcess.do.
[ February 18, 2003: Message edited by: David Hibbs ]
 
Dave Hewitson
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi David - thanks.
I understand what your saying, but the other problem is that in my action when I want to progress from screen A to screen B, my forward is linked to a screenB.do in the config file. The problem then is that the LookupDispatchAction just looks for a method in screenBAction with the same name as the one it just invoked in screenAAction - becuase no other button has been pressed in the meantime.
I don't understand enought about the inner workings of LookupDispatchAction to know how to set the action (ie the button pressed) manually to something else, for example "preProcess" that would then call that method in screenBAction.
Anyone know how to do this?
Dave
[ February 19, 2003: Message edited by: Dave Hewitson ]
 
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Chaining actions to actions has been discussed as a bad practice. As with most situations, there are cases when this is a good idea and cases when it's not. I have my feet squarely in both camps!
One trouble I've run into is that you cannot (without effort) modify the form from inside the actions, forward to another action that uses the same form, and expect that value to remain set.
Struts will repost the data from the original request into the form associated with the second action wiping out your manual setting. You can set guard properties on the form an manually prohibit the repost from changing certain attributes but in doing so you have to ask yourself if the value is worth the effort and added complexity.
You mileage may vary.
 
David Hibbs
Ranch Hand
Posts: 374
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Dave Hewitson:
I understand what your saying, but the other problem is that in my action when I want to progress from screen A to screen B, my forward is linked to a screenB.do in the config file.


Here I think is the problem. Define "progress from screen A to screen B" more clearly.
"Screen A" implies a JSP. The JSP itself doesn't do forwarding (or shouldn't) as it is the View component. It simply has a link or form that calls something else. If you simply want to link to "Screen B" but have something pre-process for screen B, link to initScreenB.do and have that forward to Screen B. Screen B can then post to another action. Keep it simple--don't try to do too much in any given place!
 
Sheriff
Posts: 6450
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Matthew Marquand:
Chaining actions to actions has been discussed as a bad practice.


<hijack>
Interesting. Do you have any links to any discussions on this, or any other references?
</hijack>
 
David Hibbs
Ranch Hand
Posts: 374
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jason Menard:
<hijack>
Interesting. Do you have any links to any discussions on this, or any other references?
</hijack>


I don't have any references, but I can tell you at least a couple reasons why to be cautious with it.
1) This likely requires both actions to use the same form bean.
2) If you make changes to the form values, the second action may not see it. The Java thread model allows local copies to be made of shared variables. So if your form bean has session scope, both the session thread and the action thread have a copy of it. When the action thread makes a change, there is no guarantee that the copy in the session thread will be updated in a timely manner. So when the next action grabs it from the session, it still sees the old value.
I've actually seen #2 happen in a slightly different case. There was a List stored in the session that a servlet updated. The result was then displayed in a JSP. Frequently, though, the JSP would not display the changes!
Anyway, I have a case in my current app where I do have a second action as a result of the first.
However, I don't share form data. My case is a search. If there is only one hit, I forward to a view action. If there are multiples, it drops to the view layer to show the list of matches.
So anyway, I also have my foot firmly in both camps. I simply preach caution in design, which is always a good thing.
 
Matthew Marquand
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I looked but couldn't find them. If memory serves me right, there was a fairly lengthy discussion of this practice (from both camps) on the struts development group. The "don't do it" camp feels that it's a sign of a poor design.
In my mind, there are times where one can cleanly introduce the execution of business logic between struts-config indicated actions increasing encapsulation and decoupling navigational decision points from actions dealing purely with the exit from the page.
 
Jason Menard
Sheriff
Posts: 6450
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That all seems to make sense. Like David, I've used discrete view actions which may or may not have been forwarded to by another action. I've been lucky up to now and it's not been an issue, but definitely something to keep in mind.
 
Dave Hewitson
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What I'm referring to is outlined by Ted Husted at http://husted.com/struts/catalog.html in the "Link only to actions" section.
David - wrt "progress from screen A to screen B", I mean simply doing a forward in the actionA, but in this case the forward is screenB.do rather than screenB.jsp - in this way I can do some screen preprocessing in the screenB action, and then use another forward to the jsp.
The problem is that when using LookupDispatchAction, the method called in the screenB action (or at least tries to be called) is the name of the button that was pressed on screenA. What I really need to do is to change this value to "preProcess" or something as I do a forward to screenB. This is obviously only a problem when linking to actions.
Does that make sense?
Dave
 
Matthew Marquand
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah. That makes sense. I'm sorry for bringing up the action-2-action
issue in your thread so I apologize.
The reason you're seeing the same button is that struts will repost the original
request data into the form you have associated to the preprocess
action. Struts does this when an action forwards to another action.
Since it does this, you cannot set properties in the form (in action A)
and expect to see those same values when you get into Action B
(the repost wipes them out).
We have (on rare occasions) put items in the request (as attributes) for the
second action. You also have some other options:
1) If the number of entry points to Action B is limited (in terms of the
number of different values you need to recognize), you can define
one struts-config entry for each and use the parameter value in struts
config to distinguish one entry to Action B from another
(mapping.getParameter()).
2) You can put something in the request using setAttribute() and retrieve it
in Action B using getAttribute(). I think this approach represents
the roots of the "poor design" camp since it using "out of band"
communication mechanisms.
3) Use the set-property values in struts-config for your Action B entries.
This is somewhat like approach 1 but doesn't use the parameter DTD
value. This approach requires you to define your own ActionMapping
class with the additional properties you like to define & set
inside struts config. I can give more info if you desire to use
this approach.
I hope I haven't been too far off base here. If so, ignore me .
Otherwise I hope I've helped.
 
David Hibbs
Ranch Hand
Posts: 374
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Dave Hewitson:
David - wrt "progress from screen A to screen B", I mean simply doing a forward in the actionA, but in this case the forward is screenB.do rather than screenB.jsp - in this way I can do some screen preprocessing in the screenB action, and then use another forward to the jsp.


In that case, I would suggest that you have two options (besides what has already been suggested):
1) Simplify "ActionB.do" by splitting it into two separate actions; "ActionB1.do" and "ActionB2.do" -- All that "ActionB1.do" does is the pre-processing for JSP B. All that "ActionB2.do" does is handle the requests made from JSP B.
2) Define your forward from ActionA.do as
<forward name="forwardB" path="/actionB.do?preProcess=true" />
Then in action B, if request.getParameter("preProcess") is "true", ignore the requested action and perform the pre-processing.
IMHO option 2 is the cleaner way, and it avoids having multiple entries for the same action in your struts-config.xml
 
Dave Hewitson
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for all the replies - I've certainly got a few things to try out now!
Dave.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic