You're not butting in at all. It's an open list... go for it.
I like that it's a bit more elegant in that it runs once to check the
current event against a list of pre-configured events... it's
certainly more elegant than my brute-force approach hehe. Considering
the limitations of MG's XML (like the fact that arguments can only be
simple values), I was going by Robert's explicit goal to configure
this thru ModelGlue.xml exclusively.
You could use ColdSpring's XML to create a map (a struct, really) of
events with other maps (aka structs) of values assosciated with them,
you'd have to do something like this in your controller/service/
configuration bean rig, probably either in a service (if you used
one) or in the controller (if you had no service class):
In the config bean:
<cffunction name="eventIsConfigured">
<cfargument name="eventName" />
<cfreturn structKeyExists
(variables.configuredEvents,arguments.eventName) />
</cffunction>
In the controller:
<cffunction name="trackEvent">
<cfargument name="event" />
<cfif EventTrackerConfig.eventIsConfigured(event.getValue("event"))>
...do stuff...
</cfif>
</cffuntction>
The more I think about this, though, the more I like the idea of
actually creating micro-framework to handle this, including a class
to encapsulate each event you want to configure to listen for and a
wrapper to hold a collection of the event-based classes. So you have
an EventTrackerContext that wraps each set of event, title, and
persistState values:
<bean id="trackCustomerSaveEvent"
class="com.rawlins.eventtracker.EventTrackerContext">
<property name="eventName" value="customer.save" />
<property name="title" value="Saved customer record: [customer
name]" />
<property name="persistEventState" value="eventKey1,eventKey2" />
</bean>
<bean id="trackCustomerWibbleEvent"
class="com.rawlins.eventtracker.EventTrackerContext">
<property name="eventName" value="customer.save" />
<property name="title" value="Saved customer record: [customer
name]" />
<property name="persistEventState" value="eventKey1,eventKey2" />
</bean>
<bean id="trackViewCallLog"
class="com.rawlins.eventtracker.EventTrackerContext">
<property name="eventName" value="customer.save" />
<property name="title" value="Saved customer record: [customer
name]" />
<property name="persistEventState" value="eventKey1,eventKey2" />
</bean>
<bean id="EventTrackerConfig"
class="com.rawlins.eventtracker.EventTrackerConfig">
<property name="configuredEvents">
<map>
<entry key="customer.save"><ref
bean="trackCustomerSaveEvent" /></
entry>
<entry key="customer.wibble"><ref
bean="trackCustomerSaveEvent" /
></entry>
<entry key="callLog.view"><ref
bean="trackCustomerSaveEvent" /></
entry>
</map>
</property>
</bean>
Having a wrapper class for the events you want to track works out
really well because then you can have logic at every level of the
stack. Then again I love building libraries, so what can I say? ;)
The thing I like about this being made into a framework/library/
actionpack kinda thing is that it can be used with MG, or ColdBox or
Fusebox OR Mach-II... being able to use the actionpack immediately
with MG would be cool but being able to use the underlying library
with the other frameworks would be cooler still.
In any case... I think we're getting somewhere with this...
Laterz,
J
On Oct 9, 2008, at 1:45 PM, Chris Blackwell wrote:
> Hi guys, hope i'm not butting in ;)
>
> using the onRequestStart method seems like a good way to centralise
> the tracking code, but lets say you want to track dozens of
> different actions, would all these broadcasts not have a
> performance impact on the application? i relise they would only
> check the event value and then return without performing any
> further processing, but it doesn't seem very efficient.
>
> perhaps broadcast a single trackEvent message, which can get its
> config from a coldspring bean, something like.. ...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en
For more about Model-Glue, check http://www.model-glue.com .
-~----------~----~----~----~------~----~------~--~---