David Winslow ha scritto:
> Hey all. I was recently added to this ticket:
> http://jira.codehaus.org/browse/GEOS-3436 regarding restlet route
> handling. I've attached a small patch to it that addresses the basic
> issue, but it brings to mind some larger concerns I have about
> GeoServer's Restlet route handling. Basically, routes for restlets in
> GeoServer are dynamically added based on instances of a custom
> RESTMapping class in the Spring context (example from my scriptlet
> extension since it's short):
>
> <bean id="javascriptRestletMapping"
> class="org.geoserver.rest.RESTMapping">
> <property name="routes">
> <map>
> <entry>
> <key><value>/script</value></key>
> <value>javascriptRestlet</value>
> </entry>
> <entry>
> <key><value>/script/{script}</value></key>
> <value>javascriptRestlet</value>
> </entry>
> </map>
> </property>
> </bean>
>
> This obscures some of the extra facilities provided by Restlet; there
> are some settings regarding match "scoring" etc that are made globally
> in the code that consumes this extension point. The ticket addresses
> one such decision; that all templates should use the default "starts
> with" matching mode. Since the index Restlet is routed to the empty
> string, every request matches it, if nothing else. My patch switches
> this to "entire string" matching, which I think is probably appropriate
> for this situation (this matching mode makes it less likely that
> extensions will "steal" paths from each other.)
Sounds good
> However, Restlet also provides "types" for the variables in templates,
> which we have thus far ignored, meaning all variables in templates are
> using the default type, URI_SEGMENT. However, there are further
> restrictions that might be useful (digit sequences for example) and
> relaxations that definitely would be handy, especially in light of
> requiring full matches. We would require this to, for example, provide
> a service that exposes XML documents as arbitrary-depth hierarchies.
>
> This requires calling mutator function on the Route object created when
> Router.attach is called. The function takes a map<string, variable>
> from name to variable specification, so we'd need to either set up an
> encoding for these in spring, or expose an extension point allowing
> routings to customize the Routes they generate.
Ok, I'm officially lost :-)
Where can I read more about this topic?
> Going the all-spring route, I guess we could come up with some way of
> annotating variables in routes with type info (like
> "/path/{var?uri-segment}" or something. But this would be less
> extensible and more of a pain to maintain, so I'm not going to explore
> it in depth.
>
> I guess more explicit XML would look like:
>
> <bean id="javascriptRestletMapping"
> class="org.geoserver.rest.RESTMapping">
> <property name="routes">
> <list>
> <bean class="org.geoserver.rest.Route">
> <property name="path" value="/script"/>
> <property name="restlet" ref="javascriptRestlet"/>
> </bean>
> <bean class="org.geoserver.rest.Route">
> <property name="path" value="/script/{script}"/>
> <property name="restlet" ref="javascriptRestlet"/>
> <property name="variables"><map><entry>
> <key><value>script</value></key>
> <bean class="org.restlet.util.Variable">
> <constructor-arg>9</constructor-arg>
> </bean>
> </entry></map></property>
> </bean>
> </list>
> </property>
> </bean>
I'm wondering if we can get to a compromise here that does not
force us to use heavy syntax in all cases.
Something like {script} is assumed to be a plain string without "/"
inside of it if nothing else is stated.
And then have the map just to declare what is the expected type.
Or even just:
<bean id="javascriptRestletMapping"
class="org.geoserver.rest.RESTMapping">
<property name="routes">
<map>
<entry>
<key><value>/script</value></key>
<value>javascriptRestlet</value>
</entry>
<entry>
<key><value>/script/{script}</value></key>
<value>javascriptRestlet</value>
</entry>
</map>
</property>
<property name="variableTypes">
<map>
<entry>
<key>script</key>
<!-- silly example -->
<value>numeric</key>
</map>
</property>
</bean>
> We might want to wrap Variable so we can do a bit of magic letting us
> use the name of the type instead of its numeric value, but you get the
> idea. This also exposes other features of Variable like default values.
Or alternatively:
<bean id="javascriptRestletMapping"
class="org.geoserver.rest.RESTMapping">
<property name="routes">
<map>
...
</map>
</property>
<property name="variables">
<list>
<value>
<bean class="org.geoserver.rest.Variable>
<property name="type">numeric</property>
<property name="default">0</property>
</bean>
</value>
</list>
</property>
</bean>
A pay as you go model. I think in the majority of cases our variables
are non uri portion strings and they default to null?
For this case I would prefer not to have to specify anything (would
also make for backwards compatible approach, as we just add an
optional property to the mix)
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
