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]