Rapha�l Luta said:Ate Douma wrote:<snip>
> > The control parameters prefix and type keys are all externally definable > (in spring assembly jetspeed-spring.xml) >
AFAIK, the JSR168 does not mandate that these parameters be included in the URL,
True, but...
you could keep them only in the session and never send them back to the browser.
... which might be quite a problem. Consider a RenderURL link on a page containing additional (new) request parameters. As these parameters are encoded as ControlParameters these *must* be part of the RenderURL send to the server if the user selects the link. For an ActionURL, which always results in a client redirect (Pluto implementation) a new client url can be generated without any ControlParameters. But for an RenderURL this shouldn't be done I think (certainly not for just clearing out possible ControlParameters).
You're right. To support this case, we need to have a generic and well-defined encoding scheme for storing control parameters on the URL.
<snip original proposal>
While the above will perfectly work, I think you operate within an implicit constraint of having all [/ControlParameters] readable and parseable by the browser/user. This is not a requirement IMO, even if we go and send back [/ControlParameters] to the browser and not keep them within the server session, only the server needs to be able to parse these parameters when they are sent back.
Hence you can for example have the following transformation: Unencoded control parameter string -> GZipFilter -> Base64Encoder* -> [EncodedControlParemeter]
(* I believe '/' is valid Base64 encoding so we need to modify slightly the encoding table not to allow this char but use '!' or '_' instead)
and simply append the the [EncodeControlParameter] at the end of the [GlobalNavigation] separated by a /.
Your request URL then becomes a regular one, without any specific additional delimiters; except that the last segment of the request path info is an encoded string reprsenting the [ControlParameter] that can easily be decoded by the portal.
If I understand this correctly, using this solution would result in a PortalURL like this:
[GlobalNavigation]/[Encoded ControlParameterString][?Encoded RequestParameters][#LocalNavigation]
We we will still need to encode the (ActionURL) RequestParameters because these also can contain trouble making characters. And besides that, the Portlet SPEC 30 explicitely requires it.
Yes. RequestParameters should always be correctly encoded, but then this is true in any web development environment :)
I have to think a little more about it, but I kinda like this solution as it indeed would result in a regular url, easily parseable by the portal. And also is a lot easier to implement as far as I can see right now. So +1 for this solution if it is feasible.
The only obvious disadvantages I see to doing this are: - we lose some CPU cycles on the compression/encoding - we actually *increase* the size of the URL when there's no control parameter:
<test>
[EMAIL PROTECTED]:~> echo -n "" | gzip -9 | perl -e 'use MIME::Base64; print encode_base64(<>);' | wc
1 1 29
</test>
So an empty string is 29 characters long after this process, so much for compression :)
Of course, this can be handled by not compressing if the [controlparameter] string length <= 18, which yields a base64 encoded string of at most 25 chars.
Upon parsing, you simply check the encoded string length to decide if you need to gunzip.
The only slight drawback of this conditional encoding is that if there's no control parameters to encode it makes the trailing / at the end of the path_info significant which may be somewhat conunter-intuitive, eg:
http://myportal/portal/page/mypage/?param1=1 parses as: GlobalNavigation -> /page/mypage ControlParameter -> empty RequestParameter -> param1=1
but
http://myportal/portal/page/mypage?param1=1 parses as: GlobalNavigation -> /page ControlParameter -> Base64Decode(mypage) -> 2 RequestParameter -> param1=1
which will not work.
-- Raphael Luta - [EMAIL PROTECTED] Apache Jetspeed - Enterprise Portal in Java http://portals.apache.org/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
