portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ingo Schuster <i...@raleigh.ibm.com>
Subject Re: cvs commit: jakarta-jetspeed/src/java/org/apache/jetspeed/portal/controllers CardPortletController.java
Date Thu, 26 Apr 2001 11:40:08 GMT
At 20:16 04/25/01, Raphaƫl Luta wrote:

>I'm not sure I like this patch as this simply hides the problem rather 
>than fix it
>at the source. It's best to find out which component is setting the 
>template to
>"/Ecs.jsp" and fix it because otherwise the error will crop up elsewhere...

You're right, this was probably not very clean. I changed it back and 
adopted the JetspeedTemplatePage, so that it is able to handle these sorts 
of URLs.
Here is a short description of the problem's core:

JetspeedTemplatePage takes the template parameter (e.g. "ECS") and asks the 
template service to locate the respective file in the file system.
The result ("/Ecs.jsp") is "stored" via "data.setScreenTemplate( template 
)" so that it can be retrieved by the layout class later. What I wasn't 
aware of, is that this call will set a parameter "template=/Ecs.jsp" in 
rundata's parameter list.
Now when the CardPortletController produces links, it "reposts" all 
parameters - including the template parameter that has been created through 
the setScreenTemplate call.
(I don't really like that internal variables get part of a URL this way...)
However, when the general error page is displayed, the programm flow comes 
past JetspeedTemplatePage _two_ times; and that's why it refused to expand 
the template search path a second time - and my misconception was that this 
is indicated by a leading slash in the template string... :-(


To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message