RE: [coldbox:16488] Re: [coldbox-3.5.2] List of Registered Interceptors

Now the question is, of course, I can just issue that command to get the information, but I don’t know if that is a list of registered interceptors or simply the settings…

Those are just the settings that existed when the framework loaded.

By itself, a plugin that provides just a list is probably wasteful but one that can do a bit more makes some sense.

What else where you thinking if having your plugin do?

The change in question really is this: Is this a plugin candidate or is there a better way to expose this kind of functionality using coldbox?

Still unclear on what functionality you’re looking for. Coldbox has methods to retrieve the actual registered interceptors which I sent in my first post. Are you just looking for a place to store some convenience methods?

Talk to us about what you’re trying to get your app to do.

Brad

Slight change of question.

So, I dug into getting the configuration information and found:

controller.getConfigSettings().interceptorconfig.interceptors

dishes out an array of the interceptors. If that is not the best way to accomplish this, please chime in.

Now the question is, of course, I can just issue that command to get the information, but I don’t know if that is a list of registered interceptors or simply the settings…so I had the thought that I’d write a plugin that provides the simple list but can also use the other functions in the api that allow me to get named interceptors from the pool of registered ones. By itself, a plugin that provides just a list is probably wasteful but one that can do a bit more makes some sense.

The change in question really is this: Is this a plugin candidate or is there a better way to expose this kind of functionality using coldbox?

Mike

Brad,

I think that you have been answering my questions all along, save two…though I think one has become self evident.

That one is this: the functions we have been discussing that return back structs of interceptors…if they exist, they are registered right? I think that has now become evident to me.

The second…I think it would be nice to have some good combination structure of interceptors that are registered and what states they register…and between you and the api docs, that has been answered. So the question I ended up with was whether or not this was a good plugin candidate (not necessarily for everyone, just for me and what I’m doing).

I guess one of the reasons I ask is because I still get confused on where or how I should design my code when it comes to interacting with CB. Interceptors are what I tend toward for a lot of customized functionality and those often need to interact with CB configuration / utility functions. Next are view helpers and application helper asking myself the obvious questions…does this function need to be available to everything or is it unique to this or many views.

But plugins are something I’ve not really had a use for…which can suggest that I don’t understand their use or that they might be more useful to me than I seem to think.

Either way, I want a simple function that hides the CB interaction from my other developers and allows us to get a list (simple enough) or provides a more complex structure combining interceptor and states, description, etc. This is mostly for debugging but at some point there will be a system level interface the admin users can interact with that will show them what interceptors are loaded…mostly as a support mechanism. Later, this system will register interceptors from database entries and some interceptors clients may have, and some clients may not have access to.

Thanks,

Mike