Adam:
I am someone who switched to OBD in the past 10 months or so and I too have
found a few cases where the engine performed differently than ACF. These
differences were annoying at first since it took time for me to track them
down, create a reproducible example, submit a ticket and then wait for a
response (especially since I was on a deadline and I am a contractor who
cannot bill the time it took to document the issues).
I sat back and calmed down a bit and thought about what the OBD engine
really stood for ... OPEN source software ... where, in my opinion, the
user community is just as important to the success of the platform as the
core engineers. You are a part of the community and your findings and
examples only make the platform better for EVERYONE; thank you. That being
said (I usually don't let cases like this get under my skin) can you please
drop your witty banter and negative tone from your email messages? In my
opinion, they do NOTHING but make you look like an ass and quite honestly I
don't think you are one; yet.
I believe it is natural for human beings to feel attacked the first moment
they read such comments as yours when you are referring to a project said
folks have spent tens of THOUSANDS of hours working on and offering for
FREE to the CFML community as an alternative to ACF. I believe Alan has
been very tempered in his responses and for that I applaud him and I think
it speaks volumes for his character. My experience with submitting tickets
to OBD I feel I got a quicker response than you and I would bet it may be
attributed to the tone of my messages. It is my opinion that the core OBD
team is very helpful and wants to produce the best CFML processing engine
out there, just give them a break and report your issues straight forward.
Again, as a member of the OBD user community, thank you for your time in
finding, testing and bringing issues to the attention of the OBD engineers.
Your actions benefit everyone, however your finger waving tone only
benefits your ego and in turn, I believe, makes a lot of folks instantly
delete your messages when in fact they could be of importance. Calm and
professional will likely serve you better. Remember, you can attract more
bees with honey than with vinegar!
Best of luck with the rest of your project, I hope you find success with
OBD.
Kind regards,
-Jeff Lucido
On Jul 24, 2010 8:49am, Adam Cameron <[email protected]> wrote:
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 and , my eyebrows raise. I don't think that's
unreasonable.
If, you know, I had found some weird thing with 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 . . 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:
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
--
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
