Helma Logo
main list history

Version 12 by hannes on 18. June 2006, 01:51

18I'm not sure we want controller/handler object mapping through route registering like Rails does 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:

Version 11 by hannes on 18. June 2006, 01:50

16Additionally, RequestMappers may have features to process support partial path mapping, including the processing of 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.

Version 10 by hannes on 18. June 2006, 01:47

26This 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.

Version 9 by hannes on 18. June 2006, 01:42

20# Try to resolve as many of the request path's elements as possible from left to rightright by sequentially invoking getChildElement().

Version 8 by hannes on 18. June 2006, 01:41

18I'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 (implemented by each RequestMapper independently, or by one common base class) would be:

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

21## If the request path can be mapped fullyfully to a handler object, invoke the default action on the handler objectit.
22## 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.
23### If this is the case, invokeinvoke the action with the given parameters.
24### OtherwiseIf not, generate 404.

Version 6 by hannes on 18. June 2006, 01:35

18I'm not sure we want controller/action controller/handler object mapping through route registering like Rails does, as it seems a bit unintuitive cumbersome after all. Maybe the best of both worlds is to use simple child element lookup for finding getting at the object/actionhandler 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:
19
20# Try to resolve as many of the request path's elements as possible from left to right.
21## If the request path can be mapped fully, invoke the default action on the handler object.
22## If there are remaining elements in the request path, ask the handler object for the last mapped element if it can resolve them to an action and valid parameters
23### If this is the case, invoke.
24### Otherwise, generate 404.
25

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

17
18I'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.

Version 4 by hannes on 18. June 2006, 01:17

16Additionally, 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 getChildElement() in RequestMappers (which may or may not be standardized) for that for this purpose, one which is able to process the whole remaining request path as an array in one single call.

Version 3 by hannes on 18. June 2006, 01:15

16Additionally, 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 getChildElement() in RequestMappers (which may or may not be standardized) for that purpose.

Version 2 by hannes on 18. June 2006, 01:14

14Alternatively, 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.

Version 1 by hannes on 18. June 2006, 01:12

1Goals:
3* Generalize the way request paths are mapped to Objects/Actions.
4* Provide a more powerful method of partial/dynamic mapping than getChildElement() in Helma 1.
5
6Non-Goals:
7
8* Break Helma 1 mapping. The new mapping must provide everything needed to implement Helma 1-like request path to HopObject mapping (including getChildElement()).
9
10=== Implementation ===
11
12At 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.
13
14Alternatively, 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. In fact, this is exactly what the current Helma 2 Subversion snapshot does.
15
16Additionally, 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*. We probably want a more powerful method than getChildElement() for that purpose.