on a related matter, I was trying to remember what the "pecking order" of scopes was that CF checks (looking for an unscoped variable of a certain name) and then tried it out on a CFC.
what I found was that, from within a CFC, FORM and URL variables on the calling page were being picked up within the CFC and treated and unscoped CFC variables (the unnamed protected scope of a CFC) if that CFC "variables-scope" variable didn't exist. they were the only scopes (that I tried) that did so. Request, Session, Application, Server all threw "Variable xxxx is undefined" errors I realise that, be design, CFC's can pick all scopes but surely this specific scenario is a bug? only FORM and URL scopes worked like this...(I was also surprised that request didn't work the same as form/url). I suppose this is a good argument for even scoping "variables.xxxx" within a CFC and not to trust in an unnamed (protected) scope. Sure that's been "mantra" for a while but I was unaware of FORM/URL interaction within a CFC if no scopes were defined... and while I'm on CFC scopes, can't the next version of CF have a "private" scope to act truly private? ... this.xxxx ... variables.xxxx ... private.xxxx ??? anyhoo, just an fyi cheers barry.b ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
