Helma Logo
main list history
previous version  overview  next version

Version 5 by hannes on 18. June 2006, 01:25

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/action mapping through route registering like Rails does, as it seems a bit unintuitive after all. Maybe the best of both worlds is to use simple child element lookup for finding the object/action, and then just convert remaining path elements to parameters as specified by the object.

     removed
     added