Hi all,
this mail should be of particular interest for David and Ate.
A few days ago I posted msg15905.html entitled "Something weird happening with fusion/pluto". In fact the navigational state IS the cause of the problem. I'd like to have your opinion about how to workaround this as several solutions are possible. Before explaining the solutions, here is the problem :
When you want to set the action of a form or have a link calling a portlet action you must use either a <portlet:actionURL> or use response.createActiontURL() method. This in turns calls the PathInfoEncodingPortalURL which extends AbstractPortalURL. This implementation of AbstractPortalURL adds a _ns:xxx element ni the request URL just after contextPath+servletPath (this is for example /jetspeed/portal/) and then appends the rest of the original request. This gives something like this : /jetspeed/portal/_ns:xxxxxx/media-type/html/user/admin/page/new.psml/js_peid/PXXXXXXX
BUT the problem is that turbine reads the URL to get its parameter hashmap ready this way : first element after context path + servlet path is meant to be parameter name, and then URL is supposed to be constructed as an alternance between paramter names and parameters values. This means that if you have such a ("normal" jetspeed)URL :
/jetspeed/portal/media-type/html/user/admin/page/new.psml/js_peid/PXXXXXXX
the resulting hashmap will be :
{ media-type=html user=admin page=news.psml js_peid=PXXXXXXX }
but it the case of the URL returned by pluto, eveything is mixed up because first element is navigational state which is not what turbine expects and has nothing to do with a key value pair. This leads to such a hashmap :
{ _ns:xxxxxx=media-type html=user admin=page js_peid=news.psml PXXXXXX= }
and of course when jetspeed wants to get the profile, it uses the parameters found in runData object and searches for the page parameter which it doesn't find. Jetspeed then constructs a default profile, pointing to default.psml page. And this is why when you click on an action button in a JSR168 portlet contained in a PSML page which is NOT default.psml you get redirected to default.psml page (which is of course not what we want).
Now possible solutions are :
- rewrite DefaultJetspeedParameterParser and override setRequest method so that it ignores the _ns:XXX element in URL (if it exists) and begins parsing right after. This is not very elegant and is clearly a workaround - Maybe configure pluto to use QueryStringEncodingPortalURL implementation of AbstractPortletURL so that ns is put as a paramter in the URL. But I would know how this is done in JSFusion and I don't know if jetspeed will be happy with this knew and unknown parameter.
Question is : Ate and David what do you think about the best way to circumvent this? Do you think it's possible to tell pluto not to add the ns element at all ?
I would personnally say that the best way would be to define a new FusionEncodingPortalURL that behaves just like PathInfoEncoding except that it adds the follwoing string : _ns/_ns: instead of simply _ns:
It would change anything for j2 since it specically looks for '_ns:' as an identifier and will allow Turbine to recognize a new _ns parameter which it would care about but at least will not break the othher parts of the URL.
The Fusion assembly script needs to use the FusionPortalURL instead of any of the regular ones.
What do you think ?
-- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]