Helma Logo
main list history
previous version  overview  next version

Version 7 by hannes on 18. June 2006, 01:37

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 have features to process remaining request path elements in a way *similar to what Ruby on Rails does|http://grazia.helma.at/pipermail/helma-user/2005-November/006145.html*. 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 through route registering like Rails does, 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 would be:

# Try to resolve as many of the request path's elements as possible from left to right.
## If the request path can be mapped fullyfully to a handler object, invoke the default action on the handler objectit.
## If there are remaining elements in the request pathpath can't be mapped fully to a handler object, ask the handler object for the last mapped element handler object if it can resolve them convert the remaining path elements to an action and valid parameters.
### If this is the case, invokeinvoke the action with the given parameters.
### OtherwiseIf not, generate 404.

     removed
     added