I've tried to localize this. It looks like the generated url s not correct. this is the source for the ajax link example href="#" onclick="var wcall=wicketAjaxGet('http://localhost:8080/web/guest/admin?p_p_id=AjaxApplication&p_p_action=1&p_p_col_id=column-1&p_p_col_count=1&',null,null, function() {return Wicket.$$(this)}.bind(this));return !wcall;" ...
notice the 'p_p_id=AjaxApplication' while this should be: 'p_p_id=AjaxApplication_WAR_wicketexamples' I'm trying to find where the this javascript fragment URL is generated in wicket because the normal, non ajax links do point to the correct location: href="http://localhost:8080/web/guest/admin?p_p_id=AjaxApplication_WAR_wicketexamples&p_p_action=1&p_p_state=normal&p_p_mode=view..... Can someone point me in the right direction? Thijs Thijs wrote: > > Hello Charly, > > Have you got any answer from Liferay jet? > We could put this in an issue in the Liferay support system. Or post a > message on the forum. > > I tried something very ugly I implemented encodeRedirectURL as encodeURL > is implemented. (copied the code) This prevents the nullpointer of > showing up. But then I get this message: > > 13:08:40,375 WARN [PortletLocalServiceImpl:138] Portlet not found for 1 > AjaxApplication > > Which probably is logical :) > I'll try and dig some further. > > Thijs > > > > > > Charles CHAHBAZIAN wrote: >> >> >> >> >> >> >> >> >> Hi Ate, >> >> Ate Douma a écrit : >> Charly >> wrote: >> >> Hello, >> >> I have the beginning of a solution ! >> >> >> Cool ! >> >> >> My code is based on Liferay's struts support >> with some adaptations. >> >> >> At this time, Guestbook portlet sample is ok, and I've made a >> modification in wicket to get Navomatic and other bookmarkablePage >> working. >> >> >> The main point is that Liferay want a new HttpServletRequest (from >> theirs object) in ServletContextProvider implementation of >> ServletContextProvider and we must copy the request's parameters from >> the original request to the new one. >> >> >> Weird, but I guess it is something Liferay specific. >> >> >> You're right. Because if I keep the same HttpServletRequest, I have a >> ClassCastException later because Liferay use these specific objects... >> >> I translate also the "_wu" >> (WicketPortlet.WICKET_URL_PORTLET_PARAMETER) parameter into differents >> parameters >> >> >> Why? >> >> The WicketPortlet dispatches to the servlet/filter using this url, so >> the underlying web container (e.g. catalina) should already provide the >> query string parameters as request parameters (as required by the >> servlet spec). >> >> >> >> You can have a look to my 3 classes at the end of this mail. >> >> >> I notice that you don't set the provided Map portletArg arguments on >> the created PortletURLImpl in createResourceURL method. >> >> You probably should... >> >> >> I tried that solution first. In that case, the url looks like that : >> http://localhost:8080/user/joebloggs/3?p_p_id=NavomaticApplication_WAR_wicketexamples&p_p_action=0&p_p_state=normal&p_p_mode=view&p_p_col_id=column-1&p_p_col_count=1&_NavomaticApplication_WAR_wicketexamples__wuview=%2Fnavomatic%2F%3Fwicket%3AbookmarkablePage%3D%253Aorg.apache.wicket.examples.navomatic.Page2 >> >> >> But the WebRequestCodingStrategy (at line : 518) use the >> request.getParameter() and on my debug sessions i saw that the >> portletArgs i've put in the PortletURLImpl parameters are available in >> the queryString but not in the parameters of the request ... (looks >> strange for me too, it seems to be a liferay's bug) >> >> >> >> >> I've got a problem for all bookmarkablePage, because the argument are >> encoded by Wicket, and Liferay encode it second time. >> >> >> Liferay shouldn't be doing that: you should get back the parameters >> previously set on a PortletURL exactly the same. >> >> Seems like a Liferay bug to me. >> >> >> About that question, as you can see in the sample url I've put, we have >> >> wicket%3AbookmarkablePage%3D%253Aorg.apache.wicket.examples.navomatic.Page2 >> you can see that the there are 2 encoding : >> 1) wicket set the parameter from >> ":org.apache.wicket.examples.navomatic.Page2" to >> "%3Aorg.apache.wicket.examples.navomatic.Page2" >> 2) Liferay encode the "%" character to "%25" >> >> When Liferay get back the Encoded parameter, the "%25" is set into "%" >> but no Wicket Code transform back the "%3A" to ":" >> >> Note : Wicket Encoding is done by : >> org.apache.wicket.request.target.coding.WebRequestEncoder : line 86 >> escapedValue = URLEncoder.encode(escapedValue, >> application.getRequestCycleSettings().getResponseRequestEncoding()); >> and I can't find a decode for this level in Wicket's code. >> >> >> The parameter received is like >> "%3Aorg.apache.wicket.examples.navomatic.Page2". So I add a call to >> decode function from "org.apache.wicket.protocol.http.RequestUtils" >> >> >> Here is my code modification (it's maybe possible to find a another >> solution too) >> >> in the class >> "org.apache.wicket.protocol.http.request.WebRequestCodingStrategy", >> method addBookmarkablePageParameters(final Request request, final >> RequestParameters parameters) >> >> (line : 521 / SVN revision : 585043) >> >> I change from >> >> final String[] components = Strings.split(requestString, >> Component.PATH_SEPARATOR); >> >> >> to >> >> final String[] components = >> Strings.split(RequestUtils.decode(requestString),Component.PATH_SEPARATOR); >> >> >> (Note: I test it with jetspeed and it works) >> >> >> The main remaining problem is about Ajax portlet. I have this Error : >> >> >> ======================================= >> >> 15:38:53,248 ERROR [[default]:731] "Servlet.service()" pour la servlet >> default a lancé une exception >> >> java.lang.NullPointerException >> >> at >> org.apache.wicket.protocol.http.WebResponse.redirect(WebResponse.java:204) >> >> at >> org.apache.wicket.protocol.http.BufferedWebResponse.close(BufferedWebResponse.java:66) >> >> >> Seems like a strange NPE to me. >> >> Looking at WebResponse.java:204, the only null reference in that code >> line could be the url string itself, but as the stacktrace indicates, >> the redirect is called from BufferedWebResponse.java:66 and there it >> only does that *if* the url != null. >> >> Can you further debug this? >> >> >> Your Right, the redirectURL is not null in BufferedWebResponse.java:66, >> but is set to null by Liferay's code on : >> com.liferay.portlet.PortletServletResponse >> code is : >> >> public String encodeRedirectURL(String url) { >> return null; >> } >> >> I don't know why, but I have to see with Liferay's Team. (very strange >> code) >> >> Ate >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> -- >> Charles CHAHBAZIAN [EMAIL PROTECTED] >> Directeur Recherche & Développement >> 15 quai Tilsitt - 69002 LYON >> tel. +33 478 38 54 18 - >> fax +33 426 68 91 68 >> >> ............................................................................... >> >> >>> www.alinto.net - >> The messaging reflex <<< >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > -- View this message in context: http://www.nabble.com/Portlet-howto-tf4587073.html#a13467811 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]