Can anyone provide insight/guidance with developing a Coldbox app with a large number of modules. We have been porting our site over to Coldbox and Fusebox and have been breaking up the original application into Coldbox modules. So far we have set up two modules that are separate applications. We are adding a new application module to handle a new type of user and the site will act very similar to a portal where one or more display widget can be laid out in predefined containers on a page. Each widget handles a single discrete responsibility like showing the upcoming weather or a stock ticker…the usual type of portal widgets. We think the best approach would be to have a nested module for each display widget under our new application module. Theoretically we could have several dozen of these module widgets.
We would have a master layout file and the widgets would be displayed dynamically, so I suspect there will be several ‘runEvent’ function calls everytime the page is viewed.
Are there any gotchas we should be looking out for?
Is having several dozen modules in a app a good practice, or are we asking for trouble?
Any issues with calling ‘runEvent’ in a layout file several times?
runEvent() multiple times inside a loop is a very inefficient way to marshall data, and requires all sorts of explicit arguments to prevent an unexpected mutation of the request context. You are better interfacing the model layer directly, which is why getInstance() is available as a supertype method in your views. Better still, pre-marshall all of your data in the handler, before it hits the view(s).
I typically use runEvent to marshall data from API methods, which already perform that function, or to provide information in to the request context that is not already available. When you fire runEvent, by default, it runs all of your normal event interception points. You can disable these by passing in prePostExempt=true but, to prevent mutation of the RequestContext, you would also need to provide explicit eventArguments ( i.e. – event, rc, prc ). If you’re only looking to leverage a view or widget from within another view, you’re better off pre-marshalling that data and then passing it explicitly to the view you want to use (add the module argument to renderView() for module views), from within the loop.
If you do decide to use runEvent(), within your loops, then I would suggest explicit event arguments and bypassing the pre/post handler methods in your arguments to that call. UI widgets are also a great use case for AJAX, as well, especially if they run remote HTTP calls. Then the remote calls won’t block the request execution, waiting for a response.
Having dozens of modules isn’t really a problem, per se. You’ll have a bit of additional overhead on the initial Application startup, during module registrion, but it’s a great way maintain separation of concern within your application.
In other words, have all of your data ready to go (retrieved, organized, formatted ), by the time you render the view and store it in the request collection or private request collection where your views can access it. You would leverage your model/service layer to process the data in to a usable form and then, once you’re in your views, you just pick the objects in the request context and go.