Proposed Functionality
Interceptors would work similar to annotations in Java where they would happen at compile time (fusebox compiletime) or a runtime. It would be upto the Interceptor to define when it was affective, this functionality would help mirror lexicons (being used at compiletime) and plugins (happening during runtime). Compiletime Interceptors would push additional code into the compilation of a fuseaction. Runtime Annotations would be created and destroyed per request and should be stateless.
Comments (1)
Feb 05, 2009
Nathan Mische says:
This is very interesting. How do you see this working? Off the top of my head I ...This is very interesting. How do you see this working? Off the top of my head I can think of a couple of approaches. One way may be to have an annotation component which defines which metadata attribute it is tied to as well as it target (circuit vs fuseaction) and retention (compile vs runtime).To make things easier you may want the annotation metadata (custom attributes) to start with some prefix like an underscore or fba (Fusebox Annotation). Given that I could have a runtime fuseaction annotation, permissions.cfc, registered to the fbaPermissions custom attribute that would intercept calls to that fuseaction. Registration could happen in fusebox.xml or by convention. Then my controller may look something like:
Another approach may be to register the annotation in the custom metadata. Something like:
With either approach the interceptors should have access to the current target's metadata, and possibly the parent's metadata if the target is a fuseaction. Also, interceptors should be able to work before, after, or around the intercepted method.
Add Comment