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 .
-~----------~----~----~----~------~----~------~--~---
