The following comment has been added to this issue:
Author: Ate Douma
Created: Thu, 1 Apr 2004 10:40 AM
Body:
Probably related to this is method
o.a.j.services.information.DynamicInformationProviderImpl.getAllParameters(PortletWindow).
That method does the decoding of NamespaceMapper encoded ActionURL parameters but is
currently nowhere used.
Furthermore, in the class javadoc comment the method is described as if it is needed
by Pluto but the DynamicInformationProvider interface of Pluto doesn't defines this
method.
Looks as if this method is obsolete right now.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-4?page=comments#action_27895
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-4
Here is an overview of the issue:
---------------------------------------------------------------------
Key: JS2-4
Summary: ActionURL parameters not accessible: wronly encoded
Type: Bug
Status: Unassigned
Priority: Blocker
Project: Jetspeed 2
Versions:
2.0-dev/cvs
Assignee:
Reporter: Ate Douma
Created: Thu, 1 Apr 2004 6:38 AM
Updated: Thu, 1 Apr 2004 10:40 AM
Environment: WindowsXP, J2SE 1.4.2_03, Tomcat 4.1.29
Description:
o.a.j.services.information.PortletURLProviderImpl.toString() encodes ActionURL
parameter using pluto's NamespaceMapper.encode(...).
This seems to be copied from pluto's
o.a.p.portalImpl.core.PortletURLProviderImpl.toString() where the exact same handling
can be found BUT there its commented out! (since the first version in cvs even).
The result of the current implementation is that ActionURL parameters are prefixed by
'Pluto_[PortletWindowId]_'. These parameters are thus not accessible by their expected
name in processAction.
In Pluto, ActionURL parameters are simply non-encoded put into the url which to me
seems perfectly fine as only one portlet can be target with an ActionURL and its id is
already encoded otherwise in the url. ActionURL parameters thus can be treated just
like normal form parameters (non of these will be propagated as render parameters
anyway).
So, my suggestion is to remove the NamespaceMapper.encode(...) handling in
o.a.j.services.information.PortletURLProviderImpl.toString() just as in Pluto.
Note: the current cvs state of ActionURL and RenderURL seems to be broken (no
parameters are rendered anymore). I tested this on a cvs checkout from 2004-03-26)
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
