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