Justin Deoliveira ha scritto: >>>> To sum up, what I'd need to properly handle the url >>>> building with the URLManglers is: >>>> - the meaning of the three URI above >>>> - how to get the proper context path out of that restlet >>>> request >>>> One final thing I've noticed is that the URLs are built >>>> piecemeal in various places in the rest code, that needs >>>> to change as the url manglers can (and will in Tike case) >>>> append kvp parameters to the URL. >>>> So it's not possible to mangle the url in one place and >>>> then adding path and kvp pieces of it later, everything >>>> has to be available in the place where the final URL >>>> is built. >>>> It does not look too bad thought, the only place I >>>> can see that builds urls is CatalogResourceBase. >>> Not sure I quite understand. Can the rest code just run the built url >>> through the mangler extension point before it encodes it? >> Yes and no. At the moment the code proxifies the URI >> before building the PageInfo, and then appends stuff (formats) >> to those proxified URIs in another class. >> What needs doing is storing the original URI in the PageInfo >> instead, and have the code building the final URL use >> the originals, extract the expected base URL (or just have it, >> like in the proposal above), add whatever else is needed to the path >> portion and finally call ResponseUtil.buildURL >> >> However that would make PageInfo something that is not a good >> idea to pass over to the templates (as it would contain >> un-proxied stuff). Suggestions? >> > So, just to ensure I understand the issue. The issue is that the rest > dispatcher will first try to mangle the url, so in the case of proxying > and the case (which I think is TIKE) append some kvp parameters. So > taken the url: > > http://host/geoserver/rest/foo.bar > > It would mangle to: > > http://proxyhost/geoserver/rest/foo.bar?key=value > > Now... the problem is that when restconfig gets a hold of this to do > resource liking it will turn it to: > > http://proxyhost/geoserver/rest/foo/child.bar
Worse, it would end up just doing and appendPath which will result in: http://proxyhost/geoserver/rest/foo.bar?key=value/child.bar > One possible solution is to have the restconfig just call buildURL > again. I guess to have this work it might be a good idea to have the > following always hold true: > > buildURL(original) = buildURL(buildURL(original)) Mind buildURL takes quite a bit of parameters: buildURL(String baseURL, String path, Map<String, String> kvp, URLType type) As for having calls twice in a row be equivalent, that is not possible as the kvp is embedded in the resulting path. We'd need some way to re-parse is back separating the base url, the path, and the kvp. As for having it work so that applying it twice would lead to the same results we'd have to ask the manglers to respect that rule. But as I said, that is not going to be possible to start with unless we provide some url unpacker method that takes a full url and turns it back into baseurl, path and params > However there is still the issue of the tempaltes which require PageInfo > to get the urls they need to spit out. One possible solution would be to > give access to give the freemarker templates access to the buildURL > function in some shape or form. Perhaps just adding a global function or > just making it a function on page info? Something like: > > ${page.uri(page.pageURI)} > > There PageInfo#uri would just be a call through to ResponseUtils.buildURL() I can try to do that, just not sure how to simplify buildURL to that point, see the above signature Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
