Dan, That's for the perspective. My question was very abstract. There's probably many ways to go about it.
byron On Oct 29, 7:32 pm, Dan Wilson <[email protected]> wrote: > 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
