Yeah, you’re just thinking of it backwards. The “local” handlers, views, etc are used first if they exist. If they don’t, THEN the external location is checked. I have a lot of handlers and views that share between several sites. I keep all the shared stuff in a “common” folder as externals and the actual site roots are pretty bare. I only put a handler or view in the actual site root if I need to “override” the external. Also, keep in mind that local handlers can literally override the external class so you can just modify a single method.
“I created a unique handler in the externals and that does not get triggered properly either”
Can you expand on that?
ColdBox Platform Evangelist
Ortus Solutions, Corp
ColdBox Platform: http://www.coldbox.org
You know I have been struggling with finding a way to accomplish this. It is not that I don’t like your solution but my client has 250 customers that share their SaaS environment and it’s only growing. In the next release of the software my goal is to be able to show that with CB as the framework we can eliminate strong concerns about change deployment and customization capabilities.
The unique handler in the externals problem is that even though I’m defining an externallocation for handlers, when I call that handler/action, I get the error suggesting that the handler is not registered.
Did you reinit the app?
As Brad said, the local handlers are the over-rides, so they should be fairly sparse. The external location is where the “core” code (handlers, views, layouts) should be…