RE: [coldbox:13967] [coldbox 3.5.0-BE] RequestContextDecorator guide

I guess we could do that. Each site, although using the same codebase through symlinks, does have its own Coldbox.cfc. I guess we could reverse it by changing the viewslocation default with the viewsexternallocation default…

Tom,

I actually did this some time ago and feel your pain, however you don’t need to hack the core to achieve this. All you need to do is write a component that extends the RC and drop it in the extensions folder, the downside to this method still is the same though. Each new version of ColdBox and we had to rewrite the render views and layouts. So that it rendered if the external location had something before the standard conventions equivalent.

The reason I ended up going down that path was more to do with code reuse than anything else, the site in question had around 80% of shared code, and that was considered core code across the sites. As the sites also used the same database, it was the best result at the time.

The idea is still sound today as it was then, to provide the use of the external views and handlers to provide a mechanism to override the core of our application if it existed. Thus if the site didn’t require a new layout or changing of the functionality it defaulted to use the standard convention over the externals.

I actually again tried to get this functionality into CB back in the days of CB 2, for that very reason that I had outlined because it would allow me to stop having to rewrite the RC extension each time CB got released with a newer version, and I still believe that it is warranted today as well. But all I got told back then was to write my own RC, and drop it in the extensions folder. That was well and good advice, but became a nightmare to continue to modify this on every CB release as well.

Now most of what we had been trying to do back then can be re factored to use interceptors, but interceptors can’t do anything about the look and feel. Modules come close but even it has the same problem with external views and layouts etc., plugins and even models.

And I know there are other things that we had done that interceptors are not quite right for as well, for example entities where set up so that if it was found in the externals location we setup it was loaded and used, over the original. that provided us with a great reason to have greater OO and still reuse the code that was similar between the entities.

I could go on and on about the benefits as well, so that others can see a need for it. But until the powers see the light, we are stuck into writing our own and extending the original, and just dropping it in the extensions folder. There is more on how I modifed the external locations at run time as well, to provide same view different themes etc., but the point is I think it is needed to be reversed the same as you.

Yeah – it seems more logical to me to have it that way around.

I’d be interested to see your extension if it’s around?