portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jetspeed-...@jakarta.apache.org
Subject [jira] Reopened: (JS2-149) Implementing PLT.7.1 PortletURL request parameter name and value encoding
Date Sun, 17 Oct 2004 13:57:51 GMT

   The following issue has been reopened.

   Reopener: Ate Douma
       Date: Sun, 17 Oct 2004 6:57 AM

character encoding isn't handled properly yet.
Because the correct character encoding is determined in the CapabilityValveImpl, instantiating
the PortalURL cannot be done yet from within the JetspeedRequestContext constructor.
A new Valve, PortalURLValveImpl is needed doing that, which thus must be invoked after the
CapabilityValveImpl and at least before the ContainerValve.

The dependency of the AbstractPortalURL on RequestContext also poses problems with the integration
in Fusion, so this dependency must be removed.
View the issue:

Here is an overview of the issue:
        Key: JS2-149
    Summary: Implementing PLT.7.1 PortletURL request parameter name and value encoding
       Type: Improvement

     Status: Reopened
   Priority: Major

    Project: Jetspeed 2
   Fix Fors:

   Assignee: Ate Douma
   Reporter: Ate Douma

    Created: Fri, 15 Oct 2004 2:07 PM
    Updated: Sun, 17 Oct 2004 6:57 AM

Several weeks ago I started a discussion on the developers list concerning
"Handling encoding requirements for the Portal URL":

I proposed an initial solution which, after a good discussion, resulted in a radical new proposal
from Raphaël Luta:

This, I have been working on for the last month bit by bit.

The resulting new URL encoding is a complete replacement of the current one which is based
on the original Pluto code base.
The problem with the current version is, for the most part, the strong coupling between the
several components involved, 
making it very difficult to extend and maintain.
So, I rewrote it from scratch and have now a new Portlet URL encoding which is much smaller
and easily extendable.

Furthermore it has several, partly new, configurable features:
- Choice where the state is maintained and to which extend:
  - all in the url (like Pluto does): 
  - windowstate and portletmode in the session (as the current J2 default): 
  - all the state in the session, including last used request parameters (new):
- Choice where the state is encoded in the url:
  - as a single path info parameter (somewhat like the current encoding):
  - as a single query string parameter (new):
- Choice how the state is encoded (new):
  - currently one supplied implementation using Base64 encoding (thereby solving the specs
requirements in one go):

All the above implementations can easily be replaced or enhanced as needed. 
So, other portals embedding Jetspeed 2 can supply their own if needed, like J1/Fusion or Jahia.
Because the new default encoding reduces the navigational state to only one parameter, this
is now a much easier and clearer task.

For J1/Fusion this *still* has to be done and will be worked on next week.

Configuring the new implementation is done in two locations:
- jetspeed-spring.xml:

  <!--  Navigational State component -->
  <bean id="org.apache.jetspeed.container.state.NavigationalStateComponent"
    <constructor-arg index="0"><value>org.apache.jetspeed.container.state.impl.SessionFullNavigationalState</value></constructor-arg>
    <constructor-arg index="1"><value>org.apache.jetspeed.container.url.impl.PathInfoEncodingPortalURL</value></constructor-arg>
    <constructor-arg index="2"><value>org.apache.jetspeed.container.state.impl.JetspeedNavigationalStateCodec</value></constructor-arg>

- jetspeed.properties:

  # Portal URL NavigationalState Parameter Name (default: _ns)

Not implemented feature: gzipping the navigational state parameter before encoding in with
In his proposal, Raphaël suggested further optimizing the encoding of the navigational state
using gzip.
I actually did implement that but it turned out that in almost no (or very unlikely situation
like one letter repeated a 100x)
this resulted in an improvement/shorter url. So, I dropped this!

Restrictions now truly enforced:
In the current J2 code base there were a few PortletURL usages which won't work now anymore.
These are *not* restrictions of the implementation but of the Portlet Specification!
- Manipulating the created PortletURL:
  In a few instances, portlet request parameter values were modified *after* the PortletURL
was created.
  This seemed a smart thing to do because the url could be reused that way.
  But, the Portlet Specification explicitly says NO on that:
    "Portlet developers should be aware that the string representation of a PortletURL may
not be a well formed URL
     but a special token at the time the portlet is generating its content." (PLT.7.1)
  Because the whole navigational state (including request parameters) are now encoded in one
Base64 encoded parameter, 
  it is NOT possible anymore to modify a created url anymore.

- Using HTTP GET as form method when using QueryStringEncodingPortalURL:
  The Portlet specification is explicit on HTTP GET usage:
    "Because some portal/portlet-containers implementations may encode internal state as part
of the URL query string, 
     portlet developers should not code forms using the HTTP GET method." (PLT.7.1)
  When using the QueryStringEncodingPortalURL, HTTP GET forms will break a created PortletURL
because the encoded
  navigational state (as stored as query string parameter) will be lost when using HTTP GET

This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message