[cfaussie] Re: Fusebox question
Hi Ryan,
If your model code was encapsulated in cfcs, you could name your queries
in the controller.. this is how I do it.
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:
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]
http://groups.google.com/group/cfaussie?hl=en
-~--~~~~--~~--~--~---
[cfaussie] Re: Fusebox question
(Sitting here burning DVDs for tomorrow's Flex course, may as well answer this now :-) On 25/02/2007, at 1:45 PM, 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". ... > Is it as simple as setting a request variable in the controller > 'request.eventObjectName' and passing that down the line? Yes, that's pretty much it at it's essence - you all agree on the names of the variables and their contents, and that becomes the interface/contract/post box number shared by the business logic and the view - you could write it down in some code comments if you wanted it to feel a bit more like a real interface, or you could make a 'model' cfc that you put in the request scope (or even in the session scope if scaling to a cluster is unlikely - I suggested this in my last Webdu talk with stateful view helper cfcs) to make the property names more formal. This is all in complete ignorance of how the more recent versions of Fusebox pass data to the view. But regardless, if I was doing a vanilla MVC-style CF app, I'd be doing the above. > That means I'll have to evaluate() it at run time, a possible > performance hit. I don't see why unless its something Fusebox specific - firstly the variable names shouldn't be changing (that's the point, the model variable names will outlive the current incarnation of the view code so there's no harm in the view hard coding these variable names for the duration of it's relatively short and brutish life), and secondly there's always the [ ] notation for accessing stuff in a scope or struct. Ah, the last DVD finished, I am going to bed :) 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] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[cfaussie] Re: Fusebox question
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: > > > > 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 -~--~~~~--~~--~--~---
[cfaussie] Re: Fusebox question
Hi Ryan, the way I write most of my fusebox apps these days is to build the entire model in CFCs, and use invoke calls where I used to use act_ and qry_ calls. This is useful for a number of reasons and specifically will answer your below query by allowing you to set the name of a query at the time you call the object. For example: That help? Toby On 25/02/2007, at 13:45 , 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: > > > > 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] > > > > > --- Life is poetry, write it in your own words --- Toby Tremayne Senior Technical Consultant Lyricist Software 0416 048 090 ICQ: 13107913 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[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: 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] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[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] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[cfaussie] Re: Fusebox question
Well yeah, typically the View is supposed to - design pattern wise - ask the controller for that information or in a more perfect world, the controller tells the view (view abstraction). Controller is the context to both pieces but in Fusebox and Mach-II you can get away with mutating the view to becoming 2-parts Controller and 1-part View. In FLEX / AJAX you could create a controller that takes behaviourless view and decorate it / inject it with behaviours via the Controller (similiar to View Helper Pattern). Overall Coldfusion isn't 100% clean OOP so go with the flow ;) heh. http://www.halhelms.com/index.cfm?fuseaction=newsletters.show&issue=032005_domainmodels That was a good article on Fusebox + Mach-II and MVC. On 2/23/07, Ryan Sabir <[EMAIL PROTECTED]> wrote: > > Hey all, > > I think there's some fundamental thing I'm missing with building an MVC > app in Fusebox. > > I have a fuse in my 'model' that runs a query to get details of an event. > Say the query is named 'qGetEvent'. > > When I'm outputing the data for that query, in a 'view' fuse, I'm > referring to that query object, as in 'qGetEvent.eventDate'. > > 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? > > >Ryan Sabir > Technical Director > > *p:* (02) 9274 8030 > *f:* (02) 9274 8099 > *m:* 0411 512 454 > *w:* www.newgency.com *Newgency Pty Ltd* > Web | Multimedia | eMarketing > > 224 Riley St > Surry Hills NSW 2010 > Sydney, Australia > > > > > > -- Regards, Scott Barnes http://www.mossyblog.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
