URL Rewriting: Understanding WSRP2Utils

Hi,

I wanted to know some details on how the URL rewriting in orbeon works
with the "Orbeon-Client: portlet" header.

Since I am not familiar with WSRP I have worked my way through the
WSRP2Utils class to understand how the escaping works. I also wrote a
Unittest (WSRP2UtilsTest) in the process.

In the URL Rewriting#known limitation[0] in the documentation it is
stated, that the input document should not contain the string
"wsrp_rewrite" at various locations. But I see that there is an escape
mechanism built into WSRP2Utils that could be used to take care. Is the
documentation up to date?

Additionally line 190 contains:
navigationalStateValue.startsWith("amp;")
Can this ever true? In which cases? As far as I can see the URL would
need to look like this: "key=value&otherKey=otherValue" for this
to come true. Can this happen?

During this process of working myself through the source code I
refactored the class so that it feels easier to read to me. I split the
class in two classes ((CopyOf)WSRP2Utils and WsrpToPortletURL) and I
have split the methods into shorter ones. I have attached both classes
to this email. If you agree that readability is increased I am happy to
contribute those classes to the project.

Thomas

[0]:
http://wiki.orbeon.com/forms/doc/developer-guide/admin/url-rewriting#TOC-Known-limitations


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Thomas,

Sorry about the delay. I had intended to look at this sooner.

We used WSRP encoding just because it was there, but we don't depend
or support WSRP otherwise, so we could also have used any other
encoding.

One reason to use an encoding is that the portlet API doesn't support
producing a response upon an action, but Orbeon Forms requires that.
So when it produces a response upon an action, the content of the
response is buffered and stored. Now the portlet URL rewriting API is
not available without a RenderResponse, which is not available upon an
action. So we WSRP-encode URLs in the buffered response, and when the
response is played back through a RenderResponse, we can catch those
encoded URLs and portlet-encode them.
I hope not! This is code with "history", and hopefully that can be
removed. A lot of the portlet handling code has changed since we
initially wrote it.

> During this process of working myself through the source code I refactored
> the class so that it feels easier to read to me. I split the class in two
> classes ((CopyOf)WSRP2Utils and WsrpToPortletURL) and I have split the
> methods into shorter ones. I have attached both classes to this email. If
> you agree that readability is increased I am happy to contribute those
> classes to the project.

Thanks a lot! If you swear that the encoding/decoding still works like
before… Does the new implementation change much regarding things like
memory usage? Would you fancy rewriting it in Scala? ;)

-Erik


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws