I've been working on a bug, [ 581199 ] Slashes in service parameters.
Basically, I'm using it as an excuse to revamp (again) how URLs are created.
I'm moving back towards prettier URLs, i.e.,
Release 2.1 /vlib/app?service=direct?parameters=foo/bar
Release 2.2 /vlib/app/direct?sp=foo&sp=bar
The service name and the service context will be encoded as additional path
info after the servlet. This is a step back towards an earlier approach at
naming.
Using Tapestry code to split multiple service parameters
("parameters=foo/bar") is problematic because slashes are also allowed
values. The new syntax lets the Servlet API handle this task for me. As I
read the Servlet API spec, servlet containers *should* return parameter
values in the order specified (it even covers the case where some parameters
are in the URL, some in the form posting, though Tapestry side-steps this
issue).
The big downside to this is that the use of path info screws up relative
paths from HTML templates to context assets (referenced in static HTML of
the template).
Technically, if you have an asset, say images/dot.gif then from the home
page (with the URL /vlib/app) you could write:
<img src="images/dot.gif" ...>
However, the URL after submitting a, say clicking the "next" button in the
browser (with URL /vlib/app/direct/Matches/browser.next?sp=2), it would be
necessary to use
<img src="../../../images/dot.gif">
Of course, with Tapestry generating all the URLs, you would never be able to
tell what the correct relative URL is.
Tapestry is solving this in 2.2 with an extension to the Shell component
(which is frequently used to render the <html> and <head> elements of the
HTML response page).
It now includes a <base href="..."> tag, that sets the base URL for the page
to match the servlet. This means that relative urls *WILL CONTINUE TO WORK
AS THEY DO IN 2.1* as long as you use a Shell component.
This approach will support slashes in the service parameters properly
(slashes are still not allowed in service context). The URLs are shorter
and, in my opinion, far more readable.
The downside is some incompatible changes to AbstractService and Gesture;
which will only affect developers who have created their own services.
In addition, I'm thinking of one other non-backwards compatible change.
Into 2.1, the service parameters array is defined as String[]. This is the
value collected by the Direct component, passed to the DirectService,
encoded in the Gesture and (when triggered) provided back by the
IRequestCycle.getServiceParameters().
However, I'm thinking of changing the array from String[] to Object[].
There isn't a good way to make this backwards compatible.
In 2.1, objects (such as Integer) are converted to strings (via toString())
before being encoded into the URL.
I would like to change this to use a DataSqueezer to convert Objects to
Strings before encoding in the URL. The Strings could then be converted
back from Strings to Objects (retaining type).
You would see the change mostly in your listener method:
2.1:
public void myListener(IRequestCycle cycle)
{
String[] parameters = cycle.getServiceParmeters();
int paramValue = Integer.parseInt(parameters[0]);
...
}
2.2 (proposed):
public void myListener(IRequestCycle cycle)
{
Object[] parameters = cycle.getServiceParameters();
int paramValue = ((Integer)parameters[0]).intValue();
...
}
The DataSqueezer supports all of the expected types (Integer, Long, Boolean,
etc.), handles null properly. It can also handle any kind of Serializable
object (though the string it generates is very long).
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
