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..
<event-handler name="ModelGlue.onRequestStart">
<broadcasts>
<message name="trackEvent" />
</broadcasts>
</event-handler>
<bean id="EventTrackerConfig" class="someGenericConfigBean">
<constructor-arg name="Events">
<list>
<map>
<entry key="event"><value>customer.save</value></entry>
<entry key="title"><value>Edited Customer:
[customer_name]</value></entry>
<entry
key="persistState"><value>customer_name,customer_id</value></entry>
</map>
</list>
</constructor-arg>
That would then a be a single broadcast, not one for every event that needed
tracking. The EmailService actionpack provides its config via ColdSpring, so
i'm guessing this is an ok way to structure an actionpack
Cheers, Chris
2008/10/9 Robert Rawlins <[EMAIL PROTECTED]>
> Jared,
>
>
>
> Excellent feedback my man, thank you. I'm all for constructing this as an
> action pack, I've used a few of them in the past and understand the
> benefits, I'm trying to work as much of my model into little action packs as
> possible for my own peace of mind, I'll post them on RIAForge as they become
> available, I have a few other little concepts brewing in my mind.
>
>
>
> Your idea about placing this in the onRequestStart makes really great
> sense, like you say, centralizing it in a location make it much more
> manageable and easy to find, especially on a larger application it'd be
> bugger hunting through it all to find them. I'll definitely take that
> concept into account. Is that available in MG:U? Something in the back of my
> brain says its only an MG:G thing?
>
>
>
> So my next thought on this process is with events which negate certain
> other events. For instance, my user has a recent events list which contains
> something like this:
>
>
>
> ยท Viewed Customer: Robert Rawlins
>
>
>
> But they then go and delete that customer! Now, if they were to click the
> link in the recent events list they would get an error as the customer no
> longer exists. Now, sure thing I could just use some tricky which notified
> them that the user that the customer had been deleted, but it would be SO
> much better to have that trace removed from the recent tasks list all
> together.
>
>
>
> How would you go about approaching that? See if you can figure it out in
> less than 3 nanoseconds ;-)
>
>
>
> Cheers J, I appreciate your thoughts,
>
>
>
> Rob
>
>
>
> *From:* [email protected] [mailto:[EMAIL PROTECTED] *On
> Behalf Of *Jared Rypka-Hauer
> *Sent:* 09 October 2008 18:10
> *To:* [email protected]
> *Subject:* [Model-Glue] Re: A recent tasks toolbar.
>
>
>
> Rob,
>
>
>
> As for being able to get the initial event data (i.e. form and url vars)
> no, MG (I don't think any of the frameworks do) doesn't have a special
> handler for that. At least I don't think it does... hrm, now I have to go
> look, damnit... one sec.
>
>
>
> >> play Jeopardy theme song <<
>
> >> lost 2 minutes to looking <<
>
>
>
> Nope... form and URL are captured per-request and passed into a collection
> that's passed into the event and thence it makes no distinction between the
> original sources for the data in the Event. Sorry. This may be something
> useful for later, though... I'll see about it.
>
>
>
> One quick point of clarification... "Viewstate_variables" is actually a
> misnomer in that the ViewState only exists in views and is an instance of
> modelglue.bean.GenericCollection, but within the controllers it's actually
> an instance of modelglue.unity.eventrequest.EventContext. Maybe call it
> "event_values" or even "eventKeys" or "persistStateKeys" or something? No
> matter, just being anal, sorry. ;)
>
>
>
> In all honesty, since you're going to be capturing only one or two
> variables for this, you have a couple approaches you could take... an array
> of structs where each struct has a particular, consistent set of keys... an
> array of ActivityHistory objects with behaviors for building links, even
> something like session.ActivityHistoryCollection that wraps an array of
> ActivityHistory objects... but in any case, you're going to be way better
> off building this to force the use of the viewstate_values for anything that
> needs values from the Event... because there's a limit set of values you
> need from the Event and there's going to be a consistent set of them for
> every single task in question, it's most likely the safest and easiest way
> to go.
>
>
>
> This is just a suggestion, so take it for what it's worth, but you might
> consider building this around ModelGlue.onRequestStart instead of every
> specific event you want to track. I can see the value of just putting the
> broadcast in each event you're going to be tracking too... this is just a
> bit more generic and, therefore, a tad more flexible. You could maintain
> your idea if you gave it XML of the following sort:
>
>
>
> <event-handler name="ModelGlue.onRequestStart">
>
> <broadcasts>
>
> <message name="trackEvent">
>
> <argument name="event" value="customer.save" />
>
> <argument name="title" value="Edited Customer:
> [customer_name]" />
>
> <argument name="persistState" value="customer_name,
> customer_id" />
>
> </message>
>
> <message name="trackEvent">
>
> <argument name="event" value="callLog.view" />
>
> <argument name="title" value="Viewed Call Log" />
>
> <argument name="persistState" value="" />
>
> </message>
>
> </broadcasts>
>
> </event-handler>
>
>
>
> This will allow you to treat your Recent Activities almost like a
> preprocessor plugin. The controller method would check
> event.getArguments("event") against event.getValue("event") on each
> broadcast to find out if this is something it's been told to track and if
> so, do it's thang... if not it would just exit. This will allow you to
> capture the data you want, when you want, without incurring a lot of
> overhead (because a cfif takes something like 3 nanoseconds to run hehe) and
> without repeating that XML on every event you're going to be tracking. It it
> also centralizes your configuration, and, potentially, gives you the option
> changing <argument name="event" value="event.name" /> to <argument
> event="events" value="event.name,otherevent.name,somefooevent.name" /> on
> the off chance that you want to run the same intercept/process on more than
> one event.
>
>
>
>
>
> I might suggest that you actually build this as an actionpack and submit it
> to the project or list it on RIA forge. Actionpacks are very cool and not
> hard to build... you'd basically build it the way you would normally and
> then <include /> it into your MG app anyway. I think something like this
> isn't an uncommon task and is an ideal candidate for an actionpack.
>
>
>
> Good idea, btw... I like it.
>
>
>
> Laterz,
>
> J
>
>
>
> On Oct 9, 2008, at 6:54 AM, Robert Rawlins wrote:
>
>
>
> Yeah, I think you're quite right, the viewstate often contains all kinds
> of objects which were retrieved by other broadcasts on the event using the
> viewstate values from any submitted forms and URL's.
>
>
>
> I'm now in two minds as to whether I should perhaps make the
> viewstate_variables argument optional, if it is not supplied then the stored
> link is formed using all available form and url variables. I could
> presumably do this by using a structAppend(), however, does MG have any
> methods for getting the base viewstate, as in, just the FORM and URL
> variables?
>
>
>
> Cheers J,
>
>
>
> Rob
>
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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 .
-~----------~----~----~----~------~----~------~--~---
