Hi Ryan, You should avoid having the controller making database calls if at all possible. The controller is like any good manager - knows what is going on and what is supposed to happen next, but never gets his hands dirty!
The controller knows only that there is something to be done, and probably knows what it needs to be done to (via URL or form variables)... So in calling the 'model' it should simply be specifying the what and the who, the model should be responsible for handling the how - including doing it's own database calls as necessary. And if that means that for some reason you wind up with the call being done twice for some good business reason, then unless it is a *really* high traffic site then take the hit and keep the two parts of the application independent. That goes for the 'view' as well. This took me a while to come to terms with but once you get it straight it works quite well. Brett B) Ryan Sabir wrote: > Thanks Robin, > > That all makes sense, but here's the bit I think I've missed... how do I > specify "the variable name the controller sets up for the view". > > At the moment in my model, a query looks like this: > > <cfquery name="qEvent" ..etc> > > In this case the model itself is setting the name of the variable. How do I > get the controller to specify this? > > Is it as simple as setting a request variable in the controller > 'request.eventObjectName' and passing that down the line? That means I'll > have to evaluate() it at run time, a possible performance hit. > > Or is there a FuseBox structure that can hold this object until its needed? > > thanks. > > > > > > From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Robin > Hilliard > Sent: Saturday, 24 February 2007 4:43 PM > To: cfaussie@googlegroups.com > Subject: [cfaussie] Re: Fusebox question > > > On 23/02/2007, at 1:55 PM, Ryan Sabir wrote: > This seems to me to be breaking the whole modularity of my solution, as the > view is expecting a query object named 'qGetEvent', in order to display its > data. I feel like I've missed something fundamental in the Fusebox docs that > will explain to me how to pass that query object down the line as a generic > object, ratehr than a specifically named variable. > > Whats the trick? > > > Hi Ryan, > > > You have to have _some_ dependencies in an application to make it work, the > trick is to eliminate the most harmful ones. Dependencies from the UI back > to the business logic/data (as you have here) are fine, as long as the > variable name the controller sets up for the view stays fixed - as long as > the control stuff doesn't need to know anything else about the view you're > fine. > > > It's like using a post office box to send a letter to someone... > > > (you don't know who and don't want to know) > > > ...you agree on the format of the letter... > > > (value objects, query column names and types) > > > ...and a post office box. > > > (a variable name). > > > When you have a letter to send you drop it into the post office box, and you > don't care or know if anyone picks it up. > > > What you avoid doing this is having to address the letter to a specific, > concrete individual... > > > (this would be like rendering bits of html or calling a function or tag > specific > to the current incarnation of the UI) > > > ...from the UI... > > > (a flighty crowd with high staff turnover - UI and other interfaces > change far more often than business logic) > > > ...if you did that, you'd have to keep changing your process to address the > letter, impacting your otherwise highly reusable letter addressing process. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
