You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@click.apache.org by Michael Hall <mh...@gmail.com> on 2008/08/24 22:38:14 UTC

Re: [Click-development] JSP forwarding issues

Where is Click getting the ".htm" extension?  Because while that is Click's
default, can't it be changed to something different in the web.xml?

Would it be better to try calling Context.getPageClass(String), and then
calling Page.setForward(Class)?


On Sun, Aug 24, 2008 at 2:05 PM, Bob Schellink <sa...@gmail.com> wrote:

> Hi all,
>
> While investigating CLK-429 I realized the way we handle explicit
> forwarding of JSP pages might not be correct.
>
> Since Click cannot render a jsp page it uses
> requestDispatcher.forward. This works fine but a problem comes up if
> one explicitly forwards to a jsp Page, by invoking
> Page.setForward("customer.jsp").
>
> What happens here is that Click will forward to customer.jsp, and as
> ClickServlet is setup to process .htm extensions (not jsp) this
> request will not process the Page Customer.java.
>
> This same situation existed for redirects but was fixed by converting
> the jsp extension to htm. This ensured that the redirect was processed
> by ClickServlet and once the page was processed, an implicit forward
> is done to the underlying jsp template.
>
> Should we not do the same for forwards? In other words if a user
> explicitly sets the Page to forward, we should convert from jsp to
> htm, process the Page and then do a final forward to the jsp.
>
> To see this issue in action you can try the JSP example from trunk:
>
> http://localhost:8080/click-examples/jsp/navigation-a.htm
>
> and click on the forward link which passes a parameter. Note the
> parameter will never increase. This is because the Page we forward to
> is never processed.
>
> Should we change this behavior in 1.5-RC1?
>
> regards
>
> bob
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Click-development mailing list
> Click-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/click-development
>

Re: JSP forwarding issues

Posted by Bob Schellink <sa...@gmail.com>.
Michael Hall wrote:
> 
> How about making Page.setForward bypass 
> HttpServletRequest#getRequestDispatcher if Context#getPageClass finds a 
> matching page class.  If the intention is to run the Page class for the 
> path, can we do that directly in Click without falling back to the 
> Servlet mechanisms?


Interesting approach. One to thing to watch out for here is that 
filters will be bypassed.

Regardless of how we do it (RequestDispatcher or direct) I am just not 
sure we second guess the user when they forward or redirect to a jsp 
page. As nobody has raised an issue about this, perhaps the current 
behavior is correct?

In fact the one issue that was raised seemed to indicate that redirect 
should not convert from jsp to htm.

Re: [Click-development] JSP forwarding issues

Posted by Michael Hall <mh...@gmail.com>.
>
> Not currently. While its possible to map to another extension things
> doesn't work as expected. Click also ships with default templates such
> as error.htm and no-page-found.htm, so if the extension is changed
> those templates will have to be renamed too. Not a smooth process.
>

That's less than ideal.  Maybe we shouldn't let people change the extension,
if changing it will cause problems.  A discussion for another thread though.


>
> HttpServletRequest#getRequestDispatcher only works with paths. In
> order to forward Click has to convert the class to a path ->
> Context.getPagePath(Class). In fact Page.setForward(Class) looks up
> the path and delegates to Page.setForward(String).


How about making Page.setForward bypass
HttpServletRequest#getRequestDispatcher if Context#getPageClass finds a
matching page class.  If the intention is to run the Page class for the
path, can we do that directly in Click without falling back to the Servlet
mechanisms?

Re: JSP forwarding issues

Posted by Bob Schellink <sa...@gmail.com>.
Hi Michael,

Michael Hall wrote:
> Where is Click getting the ".htm" extension?  Because while that is 
> Click's default, can't it be changed to something different in the web.xml?


Not currently. While its possible to map to another extension things 
doesn't work as expected. Click also ships with default templates such 
as error.htm and no-page-found.htm, so if the extension is changed 
those templates will have to be renamed too. Not a smooth process.


> 
> Would it be better to try calling Context.getPageClass(String), and then 
> calling Page.setForward(Class)?


HttpServletRequest#getRequestDispatcher only works with paths. In 
order to forward Click has to convert the class to a path -> 
Context.getPagePath(Class). In fact Page.setForward(Class) looks up 
the path and delegates to Page.setForward(String).

regards

bob