Andrea Aime wrote:
> 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
Cool, understood.
>
>> 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
I wonder if it would be better to avoid the pre-mangling by the REST
dispatcher. And instead make it mandatory for any restlet/resource that
is outputing a url call PageInfo.uri(), which does the mangling. That
should avoid the double case. And yes, it would seem to make sense to
have a convenience method which takes a single string, and breaks it
down into the components required for buildURL.
>
>> 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
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
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
