Josh Hayes-Sheen said the following on 11/26/2010 02:04 AM
1. In what I believe to be an OBD Bug, negative numbers are not
supported as cases in switch statements unless they are quoted (Which
I imagine has a performance penalty), So in the file "coldbox/system/
logging/LogLevels.cfc" the -1's must be quoted on lines 31 and 56, I
have submitted this as a bug to the OpenBlueDragon tracker
http://code.google.com/p/openbluedragon/issues/detail?id=290
Thanks for the bug report. I wouldn't assume that quoting the value is
a performance penalty. IIRC, everything is a switch/case statement is
evaluated as a string first in ACF.
2. The CFMLEngine.getVersion() function returns "1" for OpenBlueDragon
due to a change in the version number scheme, This breaks a few
things, so coldbox/system/core/cf/CFMLEngine.cfc needs to be updated,
I added a test to see if (version=1&& engine=bluedragon) then
version=7, to make it equivalent to all the checks that test for what
I assume is NewAtlanta's BlueDragon/JX, which OBD is obviously very
compatible with, I'm not sure if there are any other features that can
be enabled as OBD has been under active development for a while now,
and is probably a fair bit further along than BD/JX was when these
checks were written.
Actually, in Mach-II we differentiate between NA BD/JX and OpenBD --
their feature sets don't always align to release schedules. The
server.coldfusion.productLevel key says "GPL" which is the deciding
factor between NA and OpenBD.
Personally, I'd say this needs to be handled at the framework level
better. In the end, writing code for frameworks is a "common
denominator" situation. You have to code to where things match or
provide something special to account for the situations where things
don't match up. Here's an example:
OpenBD and Railo (and I think Railo recently fixed this) would not let a
struct key name start with a number. The ACF documentation says a-z
plus "_" etc. However ACF7 allowed keys to start with numbers. In this
case, ACF did not even implement the documentation.
3. This next one is nasty, Once CFML7 support is enabled, CB3 starts
to make use of cfinterface in it's caching interface, The
OpenBlueDragon cfinterface syntax is entirely different
Actually for a while Railo did stuff on a different level too! My
suggestion is to dump cfinterface entirely as it does not provide
anything useful and it appears that no new features will ever be
introduced for that tag. It was dead on arrival when it was released --
just Google search for the lengthy conversations on it.
In Mach-II we just mock the functions like this inside normal
cfcomponent tags. Essentially it's the same effect as using cfinterface:
<cffunction name="put" access="public" returntype="void" output="false"
hint="Puts an element by key into the cache.">
<cfargument name="key" type="string" required="true"
hint="The unique key for the data to put in the cache." />
<cfargument name="data" type="any" required="true"
hint="The data to cache." />
<cfabort showerror="This method is abstract and must be overrided." />
</cffunction>
4. There are a few other bugs I encountered while pressing onward,
including at least two that break forgebox, the first is an OBD
compatibility issue, their cfzip tag uses a zipfile attribute, instead
of just file (compatibility fix requested here:
http://code.google.com/p/openbluedragon/issues/detail?id=291):
Thanks for the bug report. The simplest fix is to just add the "file"
attribute and also allow "zipfile" for BC. This is an instance where
cfzip was part of BD before it was released in ACF and Adobe decide to
not match attributes. I can only make assumptions on why they didn't
match attributes.
.Peter
--
Open BlueDragon Public Mailing List
http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon
official manual: http://www.openbluedragon.org/manual/
Ready2Run CFML http://www.openbluedragon.org/openbdjam/
mailing list - http://groups.google.com/group/openbd?hl=en
