> > and I guess that I am a bit confused as to what it is and
> > why I should use it over some other set of standards?
>
> The point of fusebox is... "what other set of standards"?
I'd have to reject the argument that Fusebox should be used solely because
there isn't another commonly used standard in the CF development community.
There are other standards. Admittedly, none of them are nearly as widely
known or used, but they're there nonetheless.
Fusebox has some serious flaws, as far as a general-purpose methodology for
web development. Fusebox focuses solely on the application server tier,
ignoring database and client tiers which exist within every application. It
focuses on CFML portability, to the exclusion of application partitioning. I
suspect that Fusebox will run into problems in the future, as Allaire adds
object tiers to the development platform.
If Fusebox does what you need it to do, then it's an appropriate methodology
for you to use. If not, it isn't. It's as simple as that. Your argument is
analogous to saying that if lots of people drive Yugos, we should all get
Yugos so that we'll be able to use the same spare parts. The CF development
world is large enough, and CF applications vary enough, to accommodate more
than one methodology.
> The bigger scheme of things is, if you develop the killer
> calendar app, based on your shops "standards" and a fusebox
> based shop wants to use it/buy it / license and debug it...
> they need to "learn your standard coding practices". If the
> same killer calendar app was already designed to utilize fb
> code standards, their people could easily integrate your app
> into their other coding.
If it's really a "killer app", then it will probably use the methodology
that best suits it, and people will be forced to adapt to it. Maybe that's
Fusebox, maybe not. In any case, if it's written in CF, it should be
relatively self-documenting, as long as it was written well.
> Also, put that same scenerio in with
> a large client that has in-house development going on and they
> want to contract you to do a certain part of their overall
> cf system. do they want your code standards, and shop b's
> standards, and in house fusebox standards? Probably not.
I've yet to encounter a situation where we've been asked to integrate our
applications with someone else's CF applications. Most serious, non-trivial
CF applications aren't going to be simply plugged into other CF
applications. In any case, if you were to do that, the biggest problem would
be integrating data schemas, which would almost certainly guarantee that
someone's module would get modified as a result.
> There is is a bit of talk on [EMAIL PROTECTED]
> regarding reatifying the fb syandarsd to get a formalized/unified
> standard that hopefully will ultimately include "the best of
> the best" methodologies. If you disagree with what the spec's
> fb methods are - speak up and advise how they should be
> changed and improved for the better.
Unfortunately, the problem with this approach is the underlying concept that
there is, in fact, one "best way" to do things. This isn't the case - there
are alternative approaches with equal validity, in many cases. As an
extension to this, if you're pursuing different goals with your application
development, one methodology may fit those goals better than another.
There's no way that Fig Leaf could adopt Fusebox to do the kinds of
development that we do. Does that make Fusebox bad? No. Does it make us
wrong in how we do things? Again, no. The underlying problem is that Fusebox
favors some development goals, such as portability, over others, such as
application partitioning, while we favor other goals.
> As a business owner, it seems it'd make hiring a bit easier
> as well, as you would have some level of basis for assessing
> a skillset of a prospect. (minor side effect) but good one
> nonetheless.
Why couldn't you assess the skill level of a prospective hire by simply
reading their code samples and looking at applications they've developed? I
don't think I'd rate a slavish adherence to Fusebox as a plus. When we hire,
we're often less interested in seeing what they've done in CFML, which is a
pretty simple language, than we are in SQL and JavaScript and how they are
integrated with CF development.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
------------------------------------------------------------------------------
Archives: http://www.eGroups.com/list/cf-talk
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
