When an interceptor is registered either via Coldbox configuration or programatically, the configure method is fired.
If I am programatically, unregistering an interceptor, I would like to be able to trigger a unconfigure / cleanup method.
I tried putting some code in .unregister() but that didn’t work out. It would seem to be ideal to have the unconfigure() method for encapsulation rather than putting my unconfigure code outside of the interceptor.
Is there something like this in there that I missed?
Thanks,
Jade
I would recommend placing your interceptor in a module and registering/unregistering the module. Modules have more plumbing in place do with with their lifecycle.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Could you explain what your doing in your configure that would need an unconfigure?
The explanation will take some setup.
I build intranet applications and have it setup that we have a single database that manages all the applications and their respective roles.
There’s a central global repository with a single User class that is configured in the Wirebox config so that every application uses the same user / authentication mechanism and is used in more than 15 diff apps.
An application I have now, has presented a business case to be able to proxy in as a different user, ie, a manager has employees and calls the app admins because they help with something and the admin would be able say I am user and be presented with the same exact screens as the person requesting help. The admins will have different screens and options available because of the different role and the admin wouldn’t have any employees under them. So the request is the can enter a unique identifier of the manager and they will become that person. Most of the data returned is based on the managers unique identifier which is retrieved from the central global user class (used by 40 other applications) so modifying the user class is most undesirable.
The interceptor replaces the unique identifier of the logged in person (session scope) with the managers info. When they request the viewAs() (interceptor configure) it loads the interceptor and sets up some session info and substitutes in the data necessary to appear as the alt user.
The interceptor also adds a banner to every page announcing the user that their viewing as … and has a button to release the viewAs() (interceptor unconfigure) which would restore the original info into the session.
The unique identifier is a widely used reference is lots of different classes depending on what functionality is being accommodated and it seemed wasteful to setup something that says if this session.x exists then get else session.unique, especially for something that will be relatively low use but will facilitate administrators helping managers because they can see the same screen setup the same way.
I thought about using some type of mixin / aop also but the interceptor seemed simple and essentially self-contained, so nice and clean.
I liked my interceptor for the reason that when it’s registered, it’ll fix the session on configure(); every request from then on will have the view modified for the session that has the viewAs() via interception point; and (in theory) on unconfigure(), it all goes away and it doesn’t exist unless someone requests viewAs functionality again and I didn’t have to modify my shared User object.
And it actually felt portable, if I needed the same functionality in a different application.
Thanks,
Jade
Ok that was a lot more than what I was looking for, but gave me enough.
What I was looking for it what is the configure in your interceptor actually doing at the moment?
The reason I ask, is because I think you misunderstanding what the configure method is for.
The configure method is part of the WireBox, and other aspects for ColdBox. What this means is that you can preconfigure the interceptor when it is created and before it is added to the system. I maybe wrong as to this, but I believe that it was added because you can’t use the init method to configure the component, hence why the configure method is used instead.
Now once the interceptor is added to the system, it remains there until you manually remove the interceptor, which I never got the impression that this is what you are doing. And even if you are manually removing the interceptor with code, then there is still no real need for an unconfigure() method. It would be like ColdFusion having a constructor and deconstructor for the creation and destruction of Components.
Others may view this as being different, but if you consider that init is a constructor, then the configure() becomes a secondary constructor to satisfy the likes of wirebox if so needed. But that doesn’t mean you can’t use it to configure things to a certain state before it is added to ColdBox itself.
But as Components have no sense of a deconstructor, then what you’re asking for becomes mute.
If you want to ping me off list and discuss further, I would be happy to discuss it with you further. But as it stands it looks like you may need to approach this in another way. But I was more interested in what you are setting up in the configure() method and what you are wanting to add to the unconfigure() and the reason for it.
Just to tie this off for the groups community, the info dump was mostly because there are 2 things going on here: 1) the question about unconfigure() functionality of an interceptor, and 2) the off-label use of an interceptor versus other solutioning architectures.
I agree with you about my re-purposing of the configure() method and that it is essentially init() and the way I’m using it is definitely not the traditional architecture you’d find in an init() method.
I’ll send you an offline thread because I am interested how others would architect this, it’ll be later today or tomorrow because it’s a holiday here 
and there is beer to be drunk and hooliganism to take place
Thanks,
Jade