Several weeks ago I started a discussion on the developers list concerning
"Handling encoding requirements for the Portal URL":
http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=17318
I proposed an initial solution which, after a good discussion, resulted in a radical new proposal from Raphaël Luta:
http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=17320
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):
o.a.j.container.state.impl.PathNavigationalState
- windowstate and portletmode in the session (as the current J2 default):
o.a.j.container.state.impl.SessionNavigationalState
- all the state in the session, including last used request parameters (new):
o.a.j.container.state.impl.SessionFullNavigationalState
- Choice where the state is encoded in the url:
- as a single path info parameter (somewhat like the current encoding):
o.a.j.container.url.impl.PathInfoEncodingPortalURL
- as a single query string parameter (new):
o.a.j.container.url.impl.QueryStringEncodingPortalURL
- Choice how the state is encoded (new):
- currently one supplied implementation using Base64 encoding (thereby solving the specs requirements in one go):
o.a.j.container.state.impl.JetspeedNavigationalStateCodec
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"
class="org.apache.jetspeed.container.state.impl.JetspeedNavigationalStateComponent">
<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>
</bean>
- jetspeed.properties:
#----------------------------------------------------------------------------------
# Portal URL NavigationalState Parameter Name (default: _ns)
#----------------------------------------------------------------------------------
portalurl.navigationalstate.parameter.name=_ns
Not implemented feature: gzipping the navigational state parameter before encoding in with Base64.
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 forms.
Improvement
Closed
Major
Implementing PLT.7.1 PortletURL request parameter name and value encoding
