You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by devosc <de...@gmail.com> on 2005/10/16 12:13:46 UTC
RequestProcessor/Dispatcher & render page
Hi,
How does Java/Struts determine when/how to render a page fro the
current findForward path ? For some reason I cant seem to determine
how the RequestDispatcher is directly invoking the this target path
without failing in the processMapping method of RequestProcessor ?
For example, in a demo, its flow is index.html->index.jsp--> forward
to /main --> action findforward --> main.jsp, but I cant see how it
knows when/what to do with path=/main.jsp
--
devosc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RequestProcessor/Dispatcher & render page
Posted by devosc <de...@gmail.com>.
Hi Frank,
Thanks for the explanation, I realized shortly afterwards that there
<welcome-file-list> in the web.xml which pertains to the higher level
of the application/servlet... and thus like you siad unless an action
is in the mappings file the RequestProcessor wouldnt know what to do
(unless there is an action with the unkown attribute set to true).
My questioning about processCachedMessages was because, well at
atleast in PHP, that the session storage container is used while
maintaining state across multiple requests, i.e. the script loads,
stores the info in the session container and either redirects the
client (via http headers) or is available on their subseqent requests
(links)... whereas, now, if an internal forward is happening,
reloading the session messages would be a little redundant since the
internal forwards are all part of the same initial request/state....
but I think all this will work itself out while find my feet using
this mvc (in php)...
I think the <welcome-file-list> sort of clarifies things, and
nullifies the loop question...
Thanks for helping me understand...
Regards,
Greg.
--
devosc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RequestProcessor/Dispatcher & render page
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
If you invoke main.jsp, the RequestProcessor IS NOT invoked. Well, not
unless you've mapped in to .jsp.
Most people tend to map ActionServlet to .do, and I think extension
mapping is probably more prevalent than path mapping. This is done in
web.xml, same as any servlet mapping is. Remember that ActionServlet is
invoked by a request for a resource mapped to it, and it in turn invokes
RequestProcessor to, well, process the request! :)
So, the answer to your question is simply that Struts is not involved
when you request a resource that doesn't map to ActionServlet.
On to the second question... you asked what happens when
RequestProcessor.process() returns null... well, first of all, that
method doesn't return anything (I'm looking at 1.2.4 source, but I don't
believe it's any different in 1.2.7).
The long answer is that the forward or redirect was already done, if
applicable, by the call to processForwardConfig(). Now, maybe your
thinking what happens if an Action returns null? This is actually a
perfectly valid result of an Action execution. This indicates to Struts
that the response is already fully formed that no forward or redirect
should occur.
About processCachedMessages()... I think the thing to keep in mind is
that ReqestProcessor is something that ActionServlet delegates to in
order to service a request. With that in mind, it's not incorrect to
almost view ActionServlet and RequestProcessor as two parts of the same
larger whole (i.e., you could simply incorporate RequestProcessor into
ActionServlet and have it work the same). They are separate so as to
represent an extension point in the framework (i.e., custom request
processors and/or custom ActionServlets, independant of each other).
Further, with all that in mind, asking whether it would be better suited
to being called in ActionServlet is almost an invalid question... it
doesn't much matter :) You could take anything that's in
RequestProcessor and put it in ActionServlet, assuming you kept all the
ordering of events correct and such, and it would work just as well.
It's a question of being extensible and architecturally sound is all.
I wasn't sure what you were getting at with regard to a dummy action...
it sounds like you might be trying to use PHP instead of JSP, is that
right? If so, I don't know much about PHP frankly, but I remember a
discussion with regard to doing that a few months back and I was told
then that PHP is a bit different than JSP, a I recall, it's almost more
like Struts than JSP, and therefore there is a bit more to it than
simply forwarding to a PHP page. Maybe someone with more PHP knowledge
than me (since I have virtually none, it should be easy to find!) can
answer this better.
Lastly, about your question asking why a loop doesn't occur when an a
forward is returned... can you describe why you think it would? That
might be easier than trying to explain why it doesn't happen :)
Frank
devosc wrote:
> Hi,
>
> I've been looking at the src of v1.2.7.
>
> I think the real question is, what happens when no action is invoked,
> or configured in the struts xml file.
>
> For example, the initial request is to main.jsp which has no
> associated mappings in the xml config file, how does the
> RequestProcessor (or RequestDispatcher) then know how to handle this
> request ? e.g. it seems to magically know when an ActionConfig::path
> is not actually intended to be processed as an actual action but just
> to load the target jsp script.
>
> Because as far as I can tell unless one of the action mappings has an
> unkown attribute set to true then RequestProcessor::processMapping
> will throw an error.
>
> Another, possible way of considering it, is what happens when the
> RequestProcessor::process method actually returns null...
>
> There might be some semantics occuring here that I'm not experiencing
> since what I'm doing is coding the RequestProcessor for the PHP
> environment, so I might be over looking, or not experiencing something
> while just reading the source code...
>
> As far as I can tell, this morning, I need to have either, a dummy
> action that will then echo/print a response to the screen, of have a
> seperate web page that is not loaded/controlled by the
> RequestProcessor ? The latter doesnt seem feasible.
>
> Another unrelated question, but might help my understanding, is why
> does the RequestProcessor process method call the
> 'processCachedMessages' method, wouldn't this method be better suited
> to be called somewhere in ActionServlet ?
>
> I think bascially what I would like to find out, is how a returned
> findForward in Action::execute does not tie the system into a loop...
>
> G.
>
> --
> devosc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RequestProcessor/Dispatcher & render page
Posted by devosc <de...@gmail.com>.
Hi,
I've been looking at the src of v1.2.7.
I think the real question is, what happens when no action is invoked,
or configured in the struts xml file.
For example, the initial request is to main.jsp which has no
associated mappings in the xml config file, how does the
RequestProcessor (or RequestDispatcher) then know how to handle this
request ? e.g. it seems to magically know when an ActionConfig::path
is not actually intended to be processed as an actual action but just
to load the target jsp script.
Because as far as I can tell unless one of the action mappings has an
unkown attribute set to true then RequestProcessor::processMapping
will throw an error.
Another, possible way of considering it, is what happens when the
RequestProcessor::process method actually returns null...
There might be some semantics occuring here that I'm not experiencing
since what I'm doing is coding the RequestProcessor for the PHP
environment, so I might be over looking, or not experiencing something
while just reading the source code...
As far as I can tell, this morning, I need to have either, a dummy
action that will then echo/print a response to the screen, of have a
seperate web page that is not loaded/controlled by the
RequestProcessor ? The latter doesnt seem feasible.
Another unrelated question, but might help my understanding, is why
does the RequestProcessor process method call the
'processCachedMessages' method, wouldn't this method be better suited
to be called somewhere in ActionServlet ?
I think bascially what I would like to find out, is how a returned
findForward in Action::execute does not tie the system into a loop...
G.
--
devosc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RequestProcessor/Dispatcher & render page
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Take a look at the RequestProcessor class source (pre-1.3 Struts, I'm
looking at 1.2.4 at the moment). Look for the process() method. This
is, in a high-level way, where most of the work occurs in the request
processing cycle (at least the part that you are likely to be concerned
with). Specifically, near the end you'll see this:
// Call the Action instance itself
ActionForward forward = processActionPerform(request, response,
action, form, mapping);
As the comment pretty clearly states, this is where the execute() that
you as the app developer write is called. The forward you return is
grabbed. Next, you'll see this:
// Process the returned ActionForward instance
processForwardConfig(request, response, forward);
The processForwarConfig() is where the forward (or redirect) occurs. In
that method, forward.getPath() is called, which returns the path to
forward to, based on the configuration read in from struts-config.xml
when ActionServlet started up, and RequestDispatcher is used to forward
(or response.sendRedirect() for a redirect).
Have I answered the question, or did I not understand what you were asking?
Frank
devosc wrote:
> Hi,
>
> How does Java/Struts determine when/how to render a page fro the
> current findForward path ? For some reason I cant seem to determine
> how the RequestDispatcher is directly invoking the this target path
> without failing in the processMapping method of RequestProcessor ?
>
> For example, in a demo, its flow is index.html->index.jsp--> forward
> to /main --> action findforward --> main.jsp, but I cant see how it
> knows when/what to do with path=/main.jsp
>
> --
> devosc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
> .
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org