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
?
Thanks for your help
Fabrice
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
