> This was directed at Tom, but I can answer it.
lol, it was directed at whomever wanted to respond to help me understand the types of applications you are building.
> First I don’t think it was his intention of common shared code in the externals location
I believe you are correct-- that was my suggestion since it works well for me and requires no modifications of the framework.
> He clearly indicated that he would like to see the handlers external location be called first over the standard handler
Yes he did and I’m seeing if I can talk him out of it Kidding aside, there may be a benefit to a setting that defines whether or not external locations are looked at first. That being said, it may not be necessary, if your local convention was empty, and your external location was an array of locations in the order that you wanted them checked. I haven’t tried that yet nor do understand your setup enough to know it will work, but it seems like it might.
Actually I believe what he was looking for has more merit than people think, the downside comes about with plugins and models, that are DI’ed and used as singletons. But I don’t think that would be a massive problem overall.
First lets look at handlers, he wanted to know if it was possible that if the handler was in the external handler, could that be called over the standard handler. This has more merit, because it allows for core handlers to work, and if there is one in the external location then that is used instead.
I didn’t do this much with handlers myself, as I didn’t see a huge or great need for it. But I did use it on the odd occasion, and like any good OOP I could extend the standard location from the external to provide the missing pieces without falling to the DRY problems that can happen.
I might be wrong, but I believe this is the approach and method he is trying to tackle. Like I did around 3 or so years ago.
In the end due to how much the RC changed, I found it quicker and dirty to create empty handlers that just was empty and extending the original, because it was quicker and easier to do this than rewrite the constant changes of the RC decorator.
So my files quickly grew, and it is also why I maintained that I wanted separation of entities and services. Because my entities had the same fate, empty files that extended the origianal and services that did the same. My files grew very fast and CF ended up choking a lot of the time, because of the amount of files that had to be searched by CFORM.
Now its not very often that someone is going to design a site like this, but I have now worked with 4 different clients that I used this approach on. The biggest was when the code base or core application, had around 35 domains pointing to it and it kept growing. But each site had very similar modules, yes this was designed in the days prior to modules, but even today modules will suffer the same problem due to the look and feel or different functionality needed for the handlers etc.