Module Event Executions

Module event executions are done almost exactly the same way we are used to in our ColdBox applications using event syntax patterns. By now we understand that an event comes in via the URL/FORM or Remotely to the framework and then the framework decides what event to execute. We also know that we can abstract our incoming events by using the ColdBox URL Routing, but at the end of the day, we will always have an event variable in the request collection that tells the framework what event to execute. The typical event syntax pattern we have learned is:
1
// Pattern
2
event=[package.]handler[.action]
3
​
4
// Examples:
5
event=blog.posts
6
event=home.index
7
event=admin.dashboard.index
Copied!
This typical approach maps the event to a package, handler and method combination. With the addition of modules our event syntax pattern now morphs to the following:
1
// Pattern
2
event=[module:][package.]handler[.action]
3
​
4
// Examples:
5
event=blog:posts.index
6
event=cms:page.show
7
event=admin:dashboard
Copied!
As you can see, we can prefix the event syntax with a module name and then followed by a colon {module}:. This is how ColdBox can know to what module to redirect the execution to. You can even execute the runEvent() methods and target modules:
1
// Execute a viewlet in a module called viewlets:
2
#runEvent('viewlets:users.dashboard')#
Copied!
Hint Please remember that this is great for securing your applications as the event patterns you can match against with regular expressions will help you tremendously, as you can pinpoint modules directly.
In summary, the event syntax has been updated to support module executions via the {module:} prefix. However, please note that our preference is to abstract URLs and incoming event variables (via FORM/URL) by using ColdBox URL Routing. In the next section we will revise how to make module URL Routings work.

Interceptor Events

URL Routing

Last modified 3yr ago

Copy link

Edit on GitHub