This is an auto-generated topic for
SIMPLX_Controller 0.2-Beta1 by larscwallin.
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.
Added a possibility to change router Chunk in the Default Property Set.
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&action=create
www.mymodxsite.com/?id=10&service_order=432&action=update
www.mymodxsite.com/?id=10&service_order=432&action=delete
www.mymodxsite.com/?id=10&service_order=432&action
The following setup in the routing table Chunk would provide what we need,
...
"contexts":
{
"web":{
"10":{
"action":{
"*":"service_order_view",
"update":"service_order_update",
"create":"service_order_update",
"delete":"service_order_delete"
}
}
}
...
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",
"10":"handle_chunk_action",
"16":"handle_snippet_action",
"30":"handle_document_action"
}
}
}
......
Modx Controller Actions
Modx uses so called Connectors to handle ajax requests from the Manager GUI. These also trigger the SIMPLX plugin
The parameter conventions for these requests are a bit different from those who force a page reload, i will research these a bit more and get back to you.
If you want to do some detective work, use Chromes Inspector or FireBug and check out the XHR events. Please remember that these requests are almost exclusivly POST and as such params are in the header.
