Request Path Mapping

Goals:

• Generalize the way request paths are mapped to Objects/Actions.
• Provide a more powerful method of partial/dynamic mapping than getChildElement() in Helma 1.

Non-Goals:

• Break Helma 1 mapping. The new mapping must provide everything needed to implement Helma 1-like request path to HopObject mapping (including getChildElement()).

Implementation

At the lowest level, Helma 2 will employ pluggable RequestMappers to map incoming requests to objects and actions. For example, a HopObjectRequestMapper will start at the HopObject root element, sequentially get the child element for each path element and try to resolve the last element to an action.

Alternatively, there might be something like a PlainScriptFileRequestMapper that tries to resolve the request path to a JS script file in the server's document root, create a JS object from the script file and invoke an action on it. This would provide a means to use Helma without persistent objects in a way that resembles classic web scripting systems such as PHP. In fact, this is exactly what the current Helma 2 Subversion snapshot does.

Additionally, RequestMappers may support partial path mapping, including the processing of remaining request path elements in a way similar to what Ruby on Rails does. Note how Jürg's implementation has to run circles to come around the limitions of getChildElement(). We probably want a more powerful method than that for this purpose, one which is able to process the whole remaining request path as an array in one single call.

I'm not sure we want controller/handler object mapping to be part of partial path mapping, as it seems a bit cumbersome after all. Maybe the best of both worlds is to use simple child element lookup for getting at the handler object, and then just convert remaining path elements to parameters as specified by the handler object. In other words, the basic mapping algorithm (implemented by each RequestMapper independently, or by one common base class) would be:

1. Try to resolve as many of the request path's elements as possible from left to right by sequentially invoking getChildElement().
   1. If the request path can be mapped fully to a handler object, invoke the default action on it.
   2. If the request path can't be mapped fully to a handler object, ask the last mapped handler object if it can convert the remaining path elements to an action and valid parameters.
      1. If this is the case, invoke the action with the given parameters.
      2. If not, generate 404.

This is more or less a generalization of what Helma 1 does, as it allows handler objects to resolve several unmapped path elements to actions with parameters, instead of just mapping one last path element to an action, and it gives the RequestMapper and/or handler object greater freedom on how to implement this.

Pages linking to this page: Helma 1 Compatibility Layer