> IMO, it's unnecessary for people to bother creating Fusebox-related tools
> that can't adapt (or be adapted) to individual patterns of usage. Either
> keep the function flexible or the source open... that's about as close to
a
> "standard" as anyone needs in this context.
this is akin to "well if you can't get me to Mars then don't bother trying
to get to the Moon". :) The simple fact is that in order to get to the
point you want, which is adapting to YOUR style, the tool has to first be
able to adapt to SOME style. That style should be the standard, whatever
standard it turns out to be. Otherwise the developer will develop it for HIS
standard only.
And what is to motivate these tool developers? Only the idea that the list
will find them "kewl" ? There are already half a dozen PHENOMENAL rapid
development tools out there that have not caught on since their developers
(a) have no standard (in both techniques and in time-stamp) by which to
measure where their tool stands, and (b) their customers can't know if the
tool will conform to some known metric, and (c) little economic incentive to
develop anything other than a quick "weekend project" tool
(however, see below)
> Y'know, I can honestly say that I didn't start using Fusebox so I could
> experience a random group of people on a mailing list gently easing me
away
> from any practice I find useful. Call me crazy. [g]
What practices you find useful for yourself is all well and good. You should
stick with them. If it's super useful then perhaps you could help the
community by sharing them or making a tool that helps people use something
or follow a practice which you say is so useful. It would surely be welcome,
and it may of its own nature help to mold the emerging standard.
However some people are of the mind that they themselves do NOT have all the
answers and can save significant amounts of time by using such tools, or
simply having a standard to reference themselves to, by working in a
cohesive group-dynamic methodology. We're doing that right now by agreeing
to use English as our 'standard' for these messages, yet the list is open to
anyone who wants to speak in French, Swahili, and Klingon. The list doesn't
require that you speak English either on the list or at home--yet, if you DO
speak English your chances of learning useful items from the list are
enhanced. Why English? Certainly not because it's the "easiest" or the
"best" language to use as a standard. If we all waited until we had the
equivalent of a universal translator that you yearn for, then none of us
would be learning much on the list. And, from what I've seen so far, the
"random group" of people developing such tools are the same ones who
participate the most in trying to help answer questions on the list. That's
not very random at all, it hints at a non-random group of people who feel
some sort of emergent synergy will be created once a FB2.0 standard is
released.
How many of you found Jeff Peters' FuseMinder etc useful? You know why he
was able to develop even that simple tool? Because he had a rough standard
to adhere to. How many use Lee Borkman's various toolets? Did you insist on
waiting until his tool could read any format at all before using it or was
it really useful as soon as it could read the nominal fusedoc standard? No
one forces anyone to download those tools and if you don't find them useful
then it's probably no skin off those developer's backs...you got out of it
exactly what you paid for it. :) But there are people who DID find it useful
and want developers to be able to make more signficant
development-life-cycle tools-- to do that those developers need a
established grammar to parse.
When it's all said and done, I think it's like "preaching to the choir" as
the saying goes. The people who feel as you do, Roger, that you don't need
the standards or the tools because you already have enough such items in
your in-house arsenal, or that such items aren't yet "complete" enough to
allow you to use them on your own internal standards, or that for the sorts
of apps you write the standards are actually a hindrance, or whatever the
objection, well then by definition does it really matter, since you wouldn't
have employed the standard or "incomplete" tool to begin with, right? The
"right tool for the right job", right? The "Standards" issue should only
matter to those who intend to actually follow it because to everyone else
it's presumably just noise :) If it turns out to be a "bad" standard then
it will die off of its own accord anyway, and if it's good, then everyone
benefits. What's your downside?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
