Hey Byron, Your question is a little too abstract for me to hone in and give you detailed answers. I'm going to take a stab at what comes to my mind and you can send another follow up email if you like with different details.
A Model Glue event should be thought of as representative of a user Gesture. Or an event the application should be able to respond to. Here are some ideas. - ModelGlue.onRequestStart - User.doForm - Challenge.Invite In each of these cases, the application needs to be able to respond to user input and interactions specific to that request. So let's say you have an inventory report, called Inventory Report. You'd probably have an event called Inventory.Report. Let's say you were going to have several kinds of inventory reports, one for the week, one for the month and one for the quarter. You would probably not be best served by having Model Glue events for these, because the weeks, months and quarters will change. For example: Inventory.Report.WeekOfDecember12_2010 is not a good event name because you'll have to keep adding MG events each time a new week passes. You'd want to have the week be a variable: Inventory.Report&week=12 Now, let's say you had an Inventory.Report for managers and one for Workers. These may use the same query, but the user interfaces might be different. In this case, you may choose to have Inventory.Report.Manager and Inventory.Report.Worker, because then you can use different views for the UI. Of course, you could clutter up your single InventoryReportDisplay.cfm page with <cfif isManager()>sdklfjsdlfkj<cfelse>sdsdfsdfasdf</cfif>. but that makes for lots of ugly code. If you had two separate events, you could configure those events differently in Model Glue. In short, the event should stand for a single configuration of an application response to user input. One must use events and variables appropriately to have the most flexible and cleanest codebase. If I haven't answered your question, please ask it another way and I'll take another shot. DW On Fri, Oct 29, 2010 at 1:54 PM, byron <[email protected]> wrote: > Hi all. > > The app I'm working on will have the need for many types of reports. > Sorta of the standard report will be running a query to get the > necessary data, then a page to display it. From an organizational > standpoint, do most create an event-handler for each report? > > One of the things that might happen is that I may use the same query > or service (just passing different params) but need to have a > completely different report. > > Any thoughts wold be appreciated. > > Byron > > -- > Model-Glue Sites: > Home Page: http://www.model-glue.com > Documentation: http://docs.model-glue.com > Bug Tracker: http://bugs.model-glue.com > Blog: http://www.model-glue.com/blog > > 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]<model-glue%[email protected]> > For more options, visit this group at > http://groups.google.com/group/model-glue?hl=en -- William Osler - "We are here to add what we can to life, not to get what we can from life." -- Model-Glue Sites: Home Page: http://www.model-glue.com Documentation: http://docs.model-glue.com Bug Tracker: http://bugs.model-glue.com Blog: http://www.model-glue.com/blog 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
