Defining multi-segment routes in the controller.

[Mathieu Lirzin <ma...@nereide.fr>]

Hello,

To continue the work previously done on providing a REST-like API [1]
directly inside the controller DSL.  We need to support routes with
multiple segments like in the following example:

    <request-map uri="foo">…</request-map>
    <request-map uri="foo/bar">…</request-map>
    <request-map uri="foo/bar/baz">…</request-map>

The problems is that multiple-segment paths have already some semantics
attached to it.  Here are the ones I am aware of:

- *overridden view URI* is a feature which consists in dynamically
  redefining the view that must be rendered by a route for example if a
  browser sends a request with the path “/earth/moon” the request map
  with ‘uri’ attribute “earth” will run and the view whose name is
  “moon” will be rendered.

- *Query parameters inside the path* is a feature defining an
  alternative way to pass query parameters, meaning the part following
  the path like in the following example "/earth/moon?foo=1&bar=2" where
  we have the path "/earth/moon" followed by two query parameters “foo”
  and “bar” which are respectively associated with the values 1 and 2.
  With the query parameter inside the path feature the path
  “/earth/moon/~foo=1/~bar=2” will have the same interpretation as the
  previous one in OFBiz.
   
Those features needs to be adapted/removed in order to properly support
multi-segment routes.  The overridden view could be superseeded with URI
templates [2] like in the following example:

    <request-map uri="earth">
        <response name="success" type="view" value="mars"/>
    </request-map>

    <request-map uri="earth/{viewName}">
        <response name="success" type="view" from-variable="viewName"/>
    </request-map>

The query parameters in the path feature can simply be removed since we
don't need an alternative way to define query parameters.

Artemiy Rozovyk which is starting an internship at Nereide on Monday
will be working on that topic under my supervision.  Please step in if
the analysis I have made here is incomplete or is overlooking any edge
case.

Thanks.

[1] https://issues.apache.org/jira/browse/OFBIZ-4274
[2] https://tools.ietf.org/html/rfc6570

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37