Interceptor recommendations from a module point of view. This seems like it would be pretty common but perhaps I’m not thinking it through clearly. For a module to be as “self-sustaining” as possible yet integrate well “plugged into” any web application, it seems to me that there may often come a need to have global session and request needs met. For initial testing, I simply put preHandler code in every handler…but as my module grows, this starts to be a little dangerous because I am adding more and more handlers for organizational purposes. Other developers will later take this code and may need to add more functionality…so I want to protect the module as much as possible from copy/paste errors or missed updates to one handler over another just to make sure all the preHandler methods are synched.
I considered, “too bad”, at least your consistent and would say go ahead and do that anyway.
I considered, “how about not quite that bad” and inject some “global” class that has methods that do what I need.
I considered, “what about” extending the handler from an abstract and put that code in the abstract. Conceptually ok but don’t really want to play with coldbox specific concepts like “handlers”…leave that to the pros.
I considered, “can I” leverage wirebox here and “map” something as to Inject something to help…don’t think so.
I considered, “this seems like and interception” between the module and the state changes that interceptors are actually designed to work with.
So, the last one sounded like an easier approach…though I’m not convinced the best one…it certainly was easy. ModuleConfig a named interceptor warehoused in the modules directory structure and in this case, I want to start with something really simple…so no handler or any code down the line from that point in an events process, I want to be sure that the SessionStorage has a variable defaulted to “” if it does not exists, then I want to reference that value in the event so that no developer ever need worry about it existing or having value…they’ll simply always have prc.myreallyspecialvariable and not have to write any other kind of code to access that value.
Does this seem silly so far? I think it does, but there is always something wonderfully simply about its thinking…so I’ll accept comments on the silly thing if you have an alternative to anything I’ve listed thus far.
So this was pretty easy to do and seems to work pretty wonderfully…even logs the fact that the sessionStart() method ran when I start from “zero”.
Now, as I looked at this, I realize that I have to make a lot of additional effort to get at “prc” because “event” is not natively passed to sessoinStart(), which has no argument…but oooh…look…preEvent does? So now here is my thinking.
Let keep the session stuff in sessionStart() but let’s move the event related values to a more request-scoped-level and create an interceptor for preEvent, which DOES get the event and create my prc variable there. Keeps it in the request, freshens it every call…sounds good.
But then I realized, wait. Once I define these interceptors for my module, they are being kicked off on ANY session start and now on ANY event triggered…not just my module, any module, anywhere in the APP. Well now that does not seem like a good idea, does it? So…with “event” in tow, I can easily detect which event is actually being tripped and if it looks like it’s coming from my module, then that’s code I’d execute. Now this seems ok because the code was written FOR this module specifically but ideally, I only want the automatic interception point to care about this interceptor and its preEvent method if the request is coming to…well…“me”. So while it would still be checked on every request as a registered interceptor, at least the code in preEvent() would not “do anything” if it does not match a corresponding check for “hey…is this request INSIDE this module”…or the like?
This makes me feel a little dirty…but I’m not sure why exactly or if it should.
Any examples, any advice…docs seemed to get me just far enough to be able to do and investigate all this, seldom a surprise but always a pleasure…but now I’m just not sure what I should do, which way to carry this thinking.
Thanks,
Mike
