Matt said:
> To say OpenBD isn't production ready, however, is a rather ridiculous
> blanket statement. In one of my apps in particular (heavy XML processing/PDF
> generating app) I moved from CF to OpenBD and the processing runs 15-30X
> faster than it did on CF, and uses a heckuva lot less memory. How's that not
> production ready?
That's good for you. However when I see bugs in such fundamental tags
as <cfoutput> and <cfreturn>, my eyebrows raise. I don't think that's
unreasonable.
If, you know, I had found some weird thing with <cfldap> when using an
SSL connection when connecting to Novell eDirectory, then I'd shrug
and go "yeah, well I can see how they might have missed that: a bit of
an edge-case there".
But <cfoutput>. <cfreturn>. It's not heartening.
I have no problem with the performance of OBD - I'm impressed (and
indeed: it's the chief thing that distinguishes it from CF for this
project) - but I'm kinda feeling like a beta tester here. I'm sure
you disagree, and that's fine. I'm not trying to convince anyone of
anything.
Alan said:
> @Adam -- i am going to ignore your rather bold sweeping statements as i
> believe they were made in the heat of the moment and bore from
> frustration more than anything with no ill intent in mind.
Well there was no ill intent in mind (nor was there any expressed, for
that matter), but it was certainly not heat-of-the-moment. I think my
wording was well-balanced, to the point, and no histrionics in sight.
Indeed: at that moment I was rather pleased with myself for working
out WTF was going on, so I could knock together a repro case and
report it to you. (yes yes, I'm easily pleased. With myself. ;-)
Just because someone says something you don't like to hear doesn't
mean it's "ill intent", btw. It just means we don't happen to agree
on something. There's nothing wrong with that.
## Issue 1: Dynamic Expressions
> Here is a perfect example of what you call a "bug" but really could be
> argued that Adobe should never really be allowing this in the first
> place.
No, it's a bug. Because Adobe *did* allow it, and has allowed it for
about eight years (since CFMX 6.0, as far as I can tell).
Again (referring back to a previous posting here), just because one
don't happen to like something doesn't make it a bug.
> This is a classic example of where Adobe have so many
> inconsistencies with their language, that it makes it hard for the
> developer let alone the alternative engines that try to mimic this
> behavior. We have such a list of bizarre sh*t that we are still
> scratching out heads wondering "why".
How is this inconsistent? And how it is bizarre shit? It's in the
docs, after all, and has been since CFMX6.0. Admittedly they *do*
caveat this with saying "don't do it because it mixes business &
presentation logic", but that's rich... mixing business and
presentation logic was the whole raison d'etre of CF when it started
out! If they were so concerned about mixing business and presentation
logic, I don't think they would have made CF a tag-based language, I
think. But anyway, that's an irrelvant digression.
> So the rub here is: #q.id eq arguments.id# inside a string.
> Personally, if i was wanting that output in the string, i would never
> have written like that in the first place, i would have written it using:
> Evaluate("q.id eq arguments.id")
Well I agree that it's not the sort of thing I'd do in a string
(unless it was for quick and dirty debugging, like here), but I
regularly do this sort of thing:
<cfset bSomeFlag = q.id eq arguments.id>
But I'd never use evaluate() for this. Yuck. Given one can get away
without using evaluate() (and all its baggage) why would one use it?
> This is what the Evaluate() function was designed for. #..# is for
> variable output.
Pound-signs are for identifying a ColdFusion expression where it might
otherwise be identified as a literal (like... um... when it's in a
string). That's what pound-signs are for.
> Interestingly, this is only a bug when you include it as a parameter; if
> you do the same with CFOUTPUT it works fine. So there is a little issue
> there that we'll address.
Oh, so you *do* support it then. So what was all that before about
describing it as some CF idiosyncracy which really shouldn't be
allowed? You can't have it both ways ;-)
> ## Issue 2: cfreturn + cfoutput oddity
> Well spotted, and this has now been fixed. Can't really argue on
> turnaround a time for that now can you? less than 12hrs, bug accepted,
> fixed, and released --- and that is even after a rant! ;)
Yep, cheers for that. All tested and A-OK and you get a gold star for
that one. Thanks.
> Keep them coming Adam. Everything reported is making it better and
> stronger for everyone.
Heh. Be careful what you wish for ;-)
I'm about to sit down and fix up some more unit tests... I currently
have one extra failure on OBD than I do on CF, so there might be
something up there. I'll report back if I find anything. I've not
even started looking at it yet (I only just spotted it as I was typing
this para), so dunno what the difference might be. If it's an OBD
thing, you'll be hearing about it shortly after I work out what's
going on.
Cheers.
--
Adam
--
Open BlueDragon Public Mailing List
http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon
online manual: http://www.openbluedragon.org/manual/
mailing list - http://groups.google.com/group/openbd?hl=en
