Chuck Chopp wrote:
I'm looking for some good solid examples that show how to configure the JSP
files, struts-config.xml [global forwards, action mappings, form beans] and
action classes where a JSP may forward/redirect to an action [may end up
being a chain of actions]
Dear God, please let no one help him with this. Are you talking about request dispatching from a JSP to an Action? That's not a chain of Actions. Thats, well, I don't think there's a name for it -- not a good one, anyway.
before another JSP is finally displayed. The 2
books that I've been using for learning Struts are "The Struts Framework: A
Practical Guide for Java Programmers" by Sue Spielman and "Programming
Jakarta Struts" by Chuck Cavaness.
I don't know about the first book, but the second is very well written, IMHO.
Both of these books seem to be lacking
solid explanations & examples of the the full range of configurations for
forwards & actions.
Again, I have to humbly disagree with you on this point.
I keep getting the feeling that if I could see one good
comprehensive working example everything would be clear to me about how this
is supposed to work.
There's plenty of them out there. Struts itself ships with one.
I have a welcome file named "index.jsp". I'm questioning if it should be
forwarding to the JSP file "login.jsp" [which I want to protect from direct
access from the browser] or should it be forwarding to the action named
"login" [or would it be "login.do"]?
If you're going to protect a JSP from direct access, one good way is to put the JSP inside the WEB-INF and then have an action do a forward to that JSP (presumably after a security check).
The action named "login" expects to use "login.jsp" as its input, and I'm just not certain now whether forwarding to a JSP will invoke the action or if forwarding to the action will cause its input form to be displayed.
The request itself cause an action to be invoked. That is, a request comes in that matches the URI mapping to the ActionServlet. Hopes that's clear (it's crucial.) The ActionServlet receives the request and does something with it (probably calls an Action, passing it the request). Then you're action does some stuff and returns a Forward. The ActionServlet then calls a RequestDispatcher's forward method based on the Forward that was returned to it. Basically, your Action returns a forward to a JSP (better off not to chain actions), and the JSP writes to the response.
Also, in my web.xml file, I have a url-pattern of "*.do" set in my
servlet-mapping.
This is so that requests matching *.do get passed to the ActionServlet. The ActionServlet looks at the * part to pass off to the correct action.
What I'm not clear on is how/why URLs appear back in the
browser such as "login.do" and "success.do" when the global forwards that my
actions are using are called by their configured names of "login" and
"success".
I think you're confusing a "forward" with a redirect. A forward, in this context refers to an internal process in you ServletContainer. Namely, a RequestDispatcher is used to pass the request off between Servlets. In this case, we're passing the request off (internally) from the model (ActionServlet and Action) to the view(a JSP). Your URL will still be reflective of the original request (something.do), because a redirect wasn't returned to your client -- the directing was handled internally. This is a major strength of Struts.
I'm concerned about the browser backward/forward buttons and the
reload button being clicked & what this might do to navigation within my webapp.
I don't have too much for you on this. I'm almost positive that there are hooks to check for "duplicate" requests occurring within a timeframe (not nessecarily part of struts), and the backward/forward button issue has to do with the statelessness (did I type that right?) of HTTP. That is, you have to be ready for any kind of request with security and validation in mind. Struts is not going to do that for you, but it contains certain extension points, including plugins, that make it easy to consolidate this code.
- Dave
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
