Hi all. I’m writing an interceptor for my project, but I have a gray area i need someone to clear up for me…
I know how to think about controllers: they should be thin, nothing more than liaison between model and view (no queries, no business logic, etc.);
I know how to think about model objects (all sql, business logic, etc. encapsulated here);
I know how to think about views (display for the user…none to little logic, processing, etc.)
What I DON’T know how to think about are INTERCEPTORS. Using the kind of definition I have above, how would you define what should and should not be in an interceptor? How should one “think” about them in the context of MVC?
Now, for a specific question:
I have a recursive function in my interceptor that relies on an “instance-scoped” variable where the results of the recursive calls are collected (multi-level calls adding to the final result. A line such as this ( ) exists within the method). Will having an interceptor method relying on an instance-scoped variable have any bad effects in terms of multiple simultaneous users? Will i get crossover or is my interceptor safe when it comes to multiple simultaneous users? If my question doesn’t make sense, let me know and I’ll attempt to clarify more.
Interceptors can be a gamma of things. Interceptors that wrap themselves in a request flow can be considered as filters or ways to trap data, modify it and continue execution. Perfect example is the ses intercpetor, it intercepts the incoming url, manips it and then continues. Interceptors that can be plugged in at core execution points kinda follow this pattern of acting as a set of filters. They can talk to model objects also if needed.
Custom interceptors are another puppy, because these give you the ability to create observers or observable execution points that you can announce. The interceptors can then act as a controlling layer and talk to the model also. So in this approach, your interceptors become listening controllers. It can get even more funky, because maybe you want to place an event driven observer points inside of your model and then you can have model objects announcing internal events. As you can see, you can get really funky by using interceptors, I really love the usage of custom interceptors as listeners and also as ways that model objects can announce changes to themselves. They can say, hey! I just got some data in me that changed, if you use me, do something about it. The good thing, is that your model only knows how to announce stuff, so it is not coupled to actual implementations of the announcement. It just announces. You can really get interesting even driven model designs this way.
As for your instance question. Here is the deal. Interceptors are ALL singletons if they are declared in the config. So if you create instance variables, then that data is shared with all requests. So if you are setting and reading off this variable, make sure you lock the write/read operations.
Doug,
I'm going to assume the answer is "yes" since I imagine you'd have
written it differently otherwise, but here goes: what's keeping
instance.myvar in the instance scope and not in the local function
scope? is there a way to rewrite it so that it can be function local?