portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jetspeed-...@jakarta.apache.org
Subject [jira] Created: (JS2-149) Implementing PLT.7.1 PortletURL request parameter name and value encoding
Date Fri, 15 Oct 2004 21:08:53 GMT
Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/JS2-149

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: Open
   Priority: Major

    Project: Jetspeed 2
 Components: 
             Container
   Fix Fors:
             2.0-M1
   Versions:
             2.0-M1

   Assignee: Ate Douma
   Reporter: Ate Douma

    Created: Fri, 15 Oct 2004 2:07 PM
    Updated: Fri, 15 Oct 2004 2:07 PM

Description:
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.





---------------------------------------------------------------------
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message