[Coldbox-4-1-0] Modules Advice

[brett]

Hi all,

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.

1) Are there any gotchas we should be looking out for?  

2) Is having several dozen modules in a app a good practice, or are we asking for trouble?

3) Any issues with calling 'runEvent' in a layout file several times?

Thanks.

B

[Jon Clausen]

Brett,

 

`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.

 

HTH,

Jon

--
--
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
For News, visit http://blog.coldbox.org
For Documentation, visit http://wiki.coldbox.org
For Bug Reports, visit https://ortussolutions.atlassian.net/browse/COLDBOX
---
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coldbox+u...@googlegroups.com.
To post to this group, send email to col...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/coldbox/608ae112-8212-4093-805f-e71cd6f7033c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[brett]

Hi Jon,

Thanks for the input.  Can you elaborate on what you mean by 'pre-marshalling all of your data in the handler, before it hits the view'?

Thanks.

B

[Jon Clausen]

Brett,

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.

 

From: <col...@googlegroups.com> on behalf of brett <bde...@gmail.com>

Reply-To: "col...@googlegroups.com" <col...@googlegroups.com>
Date: Tuesday, May 9, 2017 at 9:15 AM
To: ColdBox Platform <col...@googlegroups.com>

--

--
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
For News, visit http://blog.coldbox.org
For Documentation, visit http://wiki.coldbox.org
For Bug Reports, visit https://ortussolutions.atlassian.net/browse/COLDBOX
---
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coldbox+u...@googlegroups.com.
To post to this group, send email to col...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/coldbox/80e2d8cf-220f-448e-9196-1852d48ba553%40googlegroups.com.