RE: [coldbox:6441] App interceptor locations

Dave, to clarify, you’re basically asking why interceptors couldn’t work the way that, say, handlers work-- where you simply drop your handler into the handlers directory (or external handler directory) and the handlerService figures how to invoke them by name automatically by using the handlersLocation convention in combination with the handler name?

That is an interesting question I’d never really thought of. You could suggest that there be an interceptorsLocation convention and the interceptorService.createInterceptor() could figure out where the CFC was located. Of course, one main difference between handlers and interceptors, is the framework goes out and finds all the handlers and registers them when the app starts up. Interceptors are created as-needed based on your config.

I, too, would be interested in hearing Luis explain why handlers, plugins, views, and layouts are “found” by the framework via conventions, yet interceptors require a full path.

Thanks!

~Brad

Exactly Brad.

As you say, I don't think it makes sense to auto-discover them, they
really should be created only by your config. But there still could be
a convention location where the framework would look for them, rather
than you need the full path. In fact, I thought there was, but maybe I
just don't remember having created the interceptors directory in my
app (this is my first CB app).

There are limits to this pathing convention though. For one thing, not
all interceptors are inside the app dir at all. For another, an
interceptor may well be more than a single file (the one I'm working
on will be I'm pretty sure), which for sanity's sake would mean a
folder inside interceptors, so the framework couldn't just look there
by name, unless it looked in all subdirectories too.

You could provide a path relative to that dir, but the framework would
have to know that that's what it was. The most obvious way to tell it
would be some magic string at the front of it, and at that point we're
not very far away from "#appMapping#.interceptors.class.MyInterceptor"
and "${AppMapping}.interceptors.class.MyInterceptor", at least in
terms of verbosity. We are kind of far though, in that the meaning is
entirely different -- one is a prefix indicating a convention-based
path, and the other is an actual functional path. An actual path is
clearly more flexible, and you could still use that if you needed to,
but on a gut level I think I prefer the convention approach.

Bottom line is that I'm ok for now, and will just have to remember to
change that config if I ever move the app. But like you say, I'd be
interested in Louis' take on all this.

Dave

LOL, I myself have asked that question lots and lots of time. Here is my reasoning. Interceptors can be ANYWHERE and they need to be registered in the EXACT order they are meant to be fired. So if we create a conventions of intercpetors, then what is the determining factor of loading them when I do the directory listing? Name? Modify date? How do I exclude them from loading but not touching my directory? Do I remove them?

Interceptors are kinda on a world on its own, and having a conventions might be easy but the drawbacks are big. What is your opinion?

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com