I was hoping the new eventPattern annotation (discussed here: http://wiki.coldbox.org/wiki/WhatsNew:3.0.0.cfm, search on
eventPattern) could be dynamic, like setting it to a property of the
Interceptor such as ="#getProperty('eventsToTrap')#". Nope, since
it's in the CFFUNCTION definition, it's expected to be a static value.
Would be great if I could set a Interceptors configuration param in
Coldbox.cfc definition to the events I want to trap in... say in the
'preProcess' function, it could be set as preProcessEventPattern or
eventPattern.preProcess parameter.
I am not sure I understand what you are asking for, the even pattern
annotation is to check that the even being called has the right permission.
If you need to do this on the preProcess then why not just add that to the
preProcess to check that they have the right permission to execute the
event?
I was hoping the new eventPattern annotation (discussed here: http://wiki.coldbox.org/wiki/WhatsNew:3.0.0.cfm, search on
eventPattern) could be dynamic, like setting it to a property of the
Interceptor such as ="#getProperty('eventsToTrap')#". Nope, since
it's in the CFFUNCTION definition, it's expected to be a static value.
Would be great if I could set a Interceptors configuration param in
Coldbox.cfc definition to the events I want to trap in... say in the
Maybe declaring the eventpattern at configuration time? Is that what you are saying.
Not surprising that the declaration is static. It's very useful
feature, and one that I've done myself manually in my custom
interceptors. But unfortunately it seems somewhat limited vs how I
did it myself. So yes... "declaring eventPattern at configuration
time" is what I'm asking. I see the usefulness of having eventPattern
being a configurable setting, especially so one can change it
dynamically based on environment (dev vs production). However that's
obviously harder to implement vs inline metadata on the function
itself (first off you'd have to specific what functions to apply the
configured eventPattern to as well as the pattern itself).
@Andrew - Not sure what you're referring to about "permissions" - it's
matching to current event so basically it's wrapping the function in a
IF event.getCurrentEvent() matches cffunction's eventPattern. You
used the word "permission" seems to imply some type of security
checking. But yes - I'm doing it myself now [basically an: IF
(event.getCurrentEvent() in getProperty('eventsToTrap') in my
preProcess]. I was hoping to tie into the new eventPattern but
changing what is now a config setting back to a hardcoded one isn't a
move I want to make.
Anyhow - its a good idea Luis and one I plan on using in some specific
cases. I just see the need to continue to wrap my interceptor
functions in an IF stmt myself as I like them as a configurable param.
Perhaps something like this? For me this would have a twofold purpose
-- As well as your eventpattern thing, it could mean that you could
enable/disable interception points on a given declaration. This could
be useful if you wanted to have one master interceptor with all your
points in it, rather than having to have several smaller interceptors
to achieve the same result (disabling, for example, a security
interception point in dev)
Well I used permission because it is basically saying is this handler
allowed to be executed in this event, which is going to give it permission
if it matches.
Can I ask a question, why would you want to change this during the running
of the application? I actualy can't think of anything off the top of my head
that would actually require that?
>Maybe declaring the eventpattern at configuration time? Is that what you
are saying.
Not surprising that the declaration is static. It's very useful
feature, and one that I've done myself manually in my custom interceptors.
But unfortunately it seems somewhat limited vs how I
did it myself. So yes... "declaring eventPattern at configuration
time" is what I'm asking. I see the usefulness of having eventPattern
being a
configurable setting, especially so one can change it
dynamically based on environment (dev vs production). However that's
obviously harder to implement vs inline metadata on the function itself
(first
off you'd have to specific what functions to apply the configured
eventPattern to as well as the pattern itself).
@Andrew - Not sure what you're referring to about "permissions" - it's
matching to current event so basically it's wrapping the function in a
IF event.getCurrentEvent() matches cffunction's eventPattern. You
used the word "permission" seems to imply some type of security checking.
But yes - I'm doing it myself now [basically an: IF
(event.getCurrentEvent() in getProperty('eventsToTrap') in my
preProcess]. I was hoping to tie into the new eventPattern but
changing what is now a config setting back to a hardcoded one isn't a move
I
want to make.
Anyhow - its a good idea Luis and one I plan on using in some specific
cases. I
just see the need to continue to wrap my interceptor functions in an IF