I'm starting to get abit lost now (all this talk about context's. :) ) but I do like the sounds of where this is going, especially the library / cross-framework elements.
Think I'd need to see it in action to fully 'get it', but definitely something to think about. I like how this discussion has got me thinking of different ways to approach things in MG.. Superb. --- James Allen -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Jared Rypka-Hauer Sent: 10 October 2008 17:17 To: [email protected] Subject: [Model-Glue] Re: A recent tasks toolbar. 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 . -~----------~----~----~----~------~----~------~--~---
