On Sat, 2 Oct 2004 00:51:30 +1200, adam <[EMAIL PROTECTED]> wrote: > Given CF is a web-development platform, and given CGI variables > intrinsically exist during a given request (are there situations they > don't?
Well, they are web server dependent so they can't be 100% relied on beyond a very basic core set of variables. Of course, if you're writing code for a specific web server / app server combo then you can justify using (certain) CGI variables. Again, it's all about tradeoffs. > Webservices or something? There are certainly requests that CF can process that don't have (all) the CGI variables you might expect - and that will likely be even more true when people start reusing CFCs as event gateways under Blackstone. So, if you want CFC reuse in that context, relying on CGI variables being directly accessible in your CFC is a Bad Thing(tm). > is it breaking encapsulation any > more than - say - using isDefined() I don't use isDefined() :) > Yesyes, "don't use out-of-scope variables", but is saying "don't use CGI > variables" not kind of like saying "don't use some inbuilt function that > returns the value of pi"? Ah, but I'm *not* saying don't use CGI variables. I'm not saying that at all. I'm saying that a properly encapsulated CFC should not use CGI variables. The CFM page that calls it or creates it can get the CGI variable value and pass it in. That allows the CFC to be reused in other situations - where CGI variables might not be available. > Sometimes dogma should give over to good sense. Tradeoffs, tradeoffs, tradeoffs. How many times do I have to say it? :) I'm not really as dogmatic as some people seem to think... > One might argue that > "you might port your code to something that doesn't furnish that CGI > variable you're relying on". Well... *sure*, that might happen. But > you're going to have more issues than just a couple of > suddenly-non-existent CGI vars. Case in point: I wrote a CFC-based application that processed sales orders that came in as XML files from an FTP server. We needed to process the same format XML data coming in via JMS. Because my CFCs were completely encapsulated, I was able to reuse them to process messages received through the Blackstone event gateway with *no* code changes. (See my blog for more details of the application in question). Could I have predicted our switch from file-based to message-based processing? Perhaps although given the initial battle to use standard format XML instead of old-school CSV files, incorporating JMS into the picture would have seemed incredibly unlikely when the app was conceived. Keeping my CFCs strictly environment-neutral was the key to this reuse. One thing the XP folks have got right is that change happens - embrace it! As you said "Well... *sure*, that might happen." and it often does, more often than we might imagine... -- Sean A Corfield -- http://www.corfield.org/ Team Fusebox -- http://www.fusebox.org/ Got Gmail? -- I have 6 invites "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
