Well, just did some testing. If you have a functions with a return type of void, it doesn't return a null (which deletes the variable) unless you do <cfreturn />. Leaving off the return causes no variable to be deleted. Which brings this...
Oddly, having a function with a return type of query (or other type) and NOT having a cfreturn at all does NOT throw an exception as I would expect. This is a bug in my opinion because if I say this function should return a query and I don't then it should error. I suspect it might be due to the use of cfinvoke with a returnvariable attribute. FYI, most of the cfthread differences in syntax bewteen cf and open bd were fixed due to a ticket I filed. .Peter -----Original Message----- From: Sean Corfield <[email protected]> Date: Tue, 8 Sep 2009 14:35:36 To: <[email protected]> Subject: [OpenBD] Re: Help getting FW/1 running on OpenBD On Tue, Sep 8, 2009 at 2:09 PM, Peter J. Farrell<[email protected]> wrote: > Have you tried <cfreturn /> in your function example? Well <cfreturn/> should be identical to omitting the return statement - that's pretty much the definition of it. As it happens, it seems none of us actually tested my shorter example :) <cffunction name="foo" returntype="any"> </cffunction> <cfset x = foo()/> <cfoutput> #isDefined('x')# #structKeyExists(variables,'x')# </cfoutput> This gives NO NO as output, which is exactly what I'd expect - and "proves" the null return assignment does indeed make the variable disappear. So the good news is OpenBD is compatible with the behavior you don't seem to like in Adobe ColdFusion and Railo... Of course that just makes the failure of FW/1 on OpenBD even more frustrating because the incompatibility in OpenBD continues to be unknown! > Your attitude Sean is rather...well, poor IMO. You should be one of the few > people that understands that framework compatibility on multiple cfml engines > isn't a snap. I went out of my way to make Edmund work on Adobe ColdFusion and OpenBD which was a PITA because the implementation of <cfthread> in OpenBD is so different to both Adobe and Railo. I'm very well aware of the incompatibilities between CFML engines that make life harder for framework developers. I was lead developer on Fusebox for two years and had to make a number of changes to ensure Fusebox ran on "those other engines" back when Adobe ColdFusion was my drug of choice (or rather Macromedia ColdFusion since I'm pretty sure my time leading Fusebox dates back that far!). That's why I came to this list and asked for help with FW/1 and why I spent hours going through the code, changing all the operators and array/struct literals so that it was compatible with OpenBD's CFMX7-level syntax support. It's why I pointed out that at Railo we've implemented a lot of what we think are "bad things" so that we are compatible with Adobe ColdFusion. To the community, compatibility *is* important, regardless of what we as CFML engine developers might think of some particularly peculiar piece of behavior. Now it seems I've identified one thing that is *not* causing FW/1 to fail on OpenBD so we must press on and find out what the real incompatibility is... Is there a way to get more information out of OpenBD when an exception occurs? Is the debug/trace tag thingy likely to help here? Can someone provide an example of how that might be used? -- Sean A Corfield -- (904) 302-SEAN Railo Technologies US -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood --~--~---------~--~----~------------~-------~--~----~ Open BlueDragon Public Mailing List http://groups.google.com/group/openbd?hl=en official site @ http://www.openbluedragon.org/ !! save a network - trim replies before posting !! -~----------~----~----~----~------~----~------~--~---
