Andrea Aime wrote: > 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)
This is more along the lines of what I had in mind as well when I heard the initial pitch yesterday. But I will freely admit I have not looked at all into the problem. > > 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
