RE: [coldbox:6452] App interceptor locations

Thanks for the explanation, Luis.

I guess I’ll back up a bit and define some of our vernacular. I could be misusing the term but to me, simply having a “convention” of where interceptors are located does not preclude the possibility of still explicitly defining when and how they are used. It just provides a consistent location in your directory structure to place them. For instance, views have a convention of where they are stored, but that doesn’t mean that all (or any) of them are going to be used. It also doesn’t trigger the framework to automatically do anything with them on startup. What it does do however, is allow me to not worry about the full path to the view file on the hard drive and simply reference it in my handler via its name. The renderer plugin is then smart enough to use its locateView() method to “look” for the view in the places that we have defined by convention to be places where views are stored.

This would still allow the config file to specify what interceptors are called and in what order, but give the option of simply referencing an interceptor in your interceptor directory by name. A convenience really, but a nice one.

Also, you said “Interceptors can be ANYWHERE”. Ok, so why? Is there a valid reason to have an interceptor be anywhere or is that simply due to the lack of a convention? I keep all my interceptors in an interceptor folder because that seems to make the most sense. Would an interceptorsExternalLocation take care of anything outside your web root such as interceptors shared between multiple apps?



I'm right with you Brad, just what I was thinking, well said. The
convention would just be to find them, configuration would still
determine what gets used and in what order.

The only reason I could think of for interceptors to be somewhere
outside /app/interceptors/ was so they could be common to multiple
apps, like ColdBox itself. But that logic applies to pretty much any
of the extension point files, and the convention location plus
external convention location strategy seems to work pretty well.

As I mentioned, I think it's important that if we're doing this by
name only, CB should look in subdirectories of the convention
locations, so you can package up a directory with multiple files as a
single interceptor. Either that, or you can provide a path form the
convention directory down.

Good ideas I think. However, it's worth noting that things work fine
as they are, once you understand *how* they work. The only rocky bit
is remembering to change their config if you move or rename the app.
It's possible paths may be different when you deploy to production, qa
test, or on the machines of other developers on the project, so making
this smoother isn't just theoretical; it could save some messing about
with the environments plugin.


I have had similar thoughts. The only question I would have if we did make an interceptors "convention" is which is easier for new CB users. Either way, like Luis had said, you can't "auto" register them because order can be very important, so even if I create an interceptor, I would still have to register it in my config before using it. Different from handlers which may be tricky at first, but I guess is already tricky. As Brad had mentioned, it would mainly be just a convenience convention.

Curt Gratz