Hi Ryan,
If your model code was encapsulated in cfcs, you could name your queries in the controller.. this is how I do it. <set name="qGetEvent" value="#application.myQueriesCfc.getEvent(myArgument='value')#" /> Cheers, Adam _____ From: Ryan Sabir [mailto:[EMAIL PROTECTED] Sent: Sunday, 25 February 2007 1:45 PM To: 'cfaussie@googlegroups.com' Subject: [cfaussie] Re: Fusebox question 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. (i.e. your business logic) If this sort of analogy appeals and you'd like to hear more, this is pretty much an extract from my MAX Asia architecture talk that I'm repeating at WebDU next month. It's about MVC and Flex but applies to ColdFusion too. Cheers, Robin ______________ Robin Hilliard Director - RocketBoots Pty Ltd Consulting . Recruitment . Software Licensing . Training http://www.rocketboots.com.au For schedule/availability call Pamela Higgins: w +61 7 5451 0362 m +61 419 677 151 f +61 3 9923 6261 e [EMAIL PROTECTED] or Direct: m +61 418 414 341 e [EMAIL PROTECTED] <BR --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
