Just a note in this regard: I have trouble with url() function in css files. Basically html designers use a relative path in css (say background: url(images/blabla.gif)) but it doesn't work in tapestry. I've tested all kind of combinations (../ / and so on) but I still don't know how it works. Will this change tackle url() function of css too? Can you please test this scenario too? And what should I do right now to tackle it (other than putting the full path in url)?
Ara. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:tapestry- > [EMAIL PROTECTED]] On Behalf Of Howard M. Lewis Ship > Sent: Sunday, July 14, 2002 10:10 AM > To: Tapestry Developer > Subject: [Tapestry-developer] Changes in 2.2: Services, URLs > > 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 ------------------------------------------------------- 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
