This is an auto-generated topic for
SIMPLX_Controller 0.1-Beta1 by larscwallin.
Brief Description:
New in version 0.2
The Controller now supports different routing depending on querystring parameter values.
The new routing table now looks like this:
{
"objectypename":"routing_table",
"createdBy":"larscwallin",
"dateCreated":"110203",
"dateLastUpdated":"110203",
"lastUpdatedBy":"larscwallin",
"contexts":{
"web":{
"1":{
"action":{
"*":"simplx_controller_example_read",
"update":"simplx_controller_example_update",
"delete":"simplx_controller_example_delete"
}
}
}
}
}
The ’*’ represents the default Snippet to call if the parameter is present but no value matched. This is not mandatory.
Also, you can now use the onWebPagePrerender event if it suits you better.
Introduction
When i have built apps on top of the Modx framework i have usually represented each object class in the application model as a page/template in Modx. Sometimes i have made a folder of the object type and had sub pages for each view type (create, update, view).
Regardless of case, i have always been in situations where i want to send a request to the server on account of a view action, such as a button click or form submit, and do some processing on the server and determine what to do next before returning the response.
Consider the following example. The id parameter represents a page/template which in turn represents a object type (in this case a service order).
www.mymodxsite.com/?id=10&create
www.mymodxsite.com/?id=10&service_order=432&update
www.mymodxsite.com/?id=10&service_order=432&delete
www.mymodxsite.com/?id=10&service_order=432&view
The following setup in the routing table Chunk would provide what we need,
...
"contexts":
{
"web":{
"10":{
"create":"service_order_create_snippet",
"update":"service_order_update_snippet"
"delete":"service_order_delete_snippet"
"view":"service_order_view_snippet"
}
...
The Snippets will then in turn handle the actual creating, updating etc.
Pretty simple right?
Every application has workflows
Workflows are defined by rules and use cases, and started by some kind of interaction.
Consider a simple e-learning app. Before entering a new step in the course, according to the use case (or maybe storyboard in this case), rules have to be evaluated to check if the user finished the previous successfully. If the check returns true the user is redirected to the new course step, if the check evaluates to false the user needs to do the previous test again.
This is where you need a routing controller. In other words SIMPLX Controller.
I will make a more elaborate tutorial about these techniques later on...
Hook up to any manager events
By using the adding the ’mgr’ context to the ’simplx_controller_routingtable’ Chunk you can catch manager events as well.
Manager events are numeric values which represent actions in the Modx manager. If you go to System/Actions you will find all system actions in the right column. Their ids are found in within the parantheses.
The following addition to the routing table will pick all actions (?a=...) for objects with id 1,
...
"contexts":
{
"mgr":{
"1":{
"a":"handle_action_snippet"
}
}
...
Since unique ids for system objects are only guaranteed per class you need to determine what object is. This means that the ’handle_action_snippet’ will have to determine for which object the action was fired. The way to do this is by reading the value of the ’a’ querystring. a=16 for example represent ’element/snippet/update’ and a=15 ’element/snippet/create’.
I will make this easier in the next version. But its still quite handy.
Look below for a bug which need to be fixed before working with manager actions.
Context Bug
Happend to hard code context key to ’web’...
This is very easy to fix by opening the Plugin and fix the row that looks kind of like this :
$current_context_key = ’web’; // modx->context->key;
I think you see what to do
Modx controller actions
Modx uses a great deal of actions which do not force a full gui reload. This makes the interface really snappy and responsive; however, the way it works today i dont think these actions trigger the System Events and thus not the Plugins.
In my humble opinion all events should be routed through the core system. This would make workflow processing, auditing etc. much easier.
I will work on some clever solution for us
How does it work?
- The plugin is executed at onHandleRequest.
- The simplx_controller_routingtable Chunk is decoded.
- A look-up is done against the routing table with the current pageid.
- Get the "routing key" (just the name of the querystring parameter) available for the pageid.
- Loop through all the elements in the HTTP request and try to match agains the "routing key".
- If a match is found evaluate which Snippet to call by looking this up in the routing table.
