> difficult to test. Also, if any of these variables are coming from the
> form
> or URL scope, it opens up huge security holes because the user could
> modify
Not necessarily, if you have an event's based system where your event
handlers register themselves as being interested in specific events eg
<cfset registerEventHandler("registerStrings", this, "onRegisterStrings")>
<!--- event, instance, functionname ---> <!--- in every object that may need
to know about the strings object --->
A centrally managed event handling mechanism could then be used to cfinvoke
only those functions that are registered as event handlers. If you so chose
to allow firing of events on a URL request, it would be impervious to
alterations and could fail gracefully with a no such event/event handler
found error. Eg
<cfset fireEvent("registerStrings", this)> <!--- event, instance --->
<!--- fired by the strings object init function --->
Fire event would look something like this...
<!--- is it a registered event handler? --->
<cfif StructKeyExists(registeredEventHandlers[counter].handlerObject,
registeredEventHandlers[counter].eventHandler)>
<!--- is it correctly registered (does the function exist?) --->
<cfif
IsCustomFunction(registeredEventHandlers[counter].handlerObject[registeredEv
entHandlers[counter].eventHandler])>
<!--- call the function --->
<cfinvoke
component="#registeredEventHandlers[counter].handlerObject#"
method="#registeredEventHandlers[counter].eventHandler#"
argumentcollection="#arguments.eventArguments#">
<cfelse>
<cfthrow
message="#registeredEventHandlers[counter].eventHandler# is not a function."
detail="#registeredEventHandlers[counter].eventHandler# could not be found
in the #getMetaData(registeredEventHandlers[counter].handlerObject).name#
CFC.">
</cfif>
<cfelse>
<cfthrow message="#registeredEventHandlers[counter].eventHandler# is
not a registered event handler." >
</cfif>
I use this method to loosely couple objects using an object factory with an
event queue so that when an object is instantiated, it notifies all the
other existing objects that are interested in knowing about its existence by
firing the event.
When the application is starting up, the event queue starts in a paused
mode, to ensure that all the core objects are created *before* the events
get fired.
It works very well indeed and allows us to flexibly build out our framework
and use already instantiated objects to speed things up.
For extra performance, with CF8, I'm building in thread support so each
<cfinvoke> gets fired on a thread. Because my events are effectively
procedures rather than functions in that they do not return anything so I
don't have to wait for a response from the threads. Theoretically, it should
make the whole event model very fast indeed. Now if only CF8 had nested
threading capabilities... :)
Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Enterprise web applications, build robust, secure
scalable apps today - Try it now ColdFusion Today
ColdFusion 8 beta - Build next generation apps
Archive:
http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:287990
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
