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 !!
-~----------~----~----~----~------~----~------~--~---
