> > that you post (e.g.., "If you can afford SQL Server, you can
> > afford its own box").
Can you even believe that I am still harping on this?
> In all honesty - today. This morning. I was reviewing a Fusebox
application,
> to fix some problems within that application. I'm familiar with the basic
> tenets of Fusebox, if for no other reason than I run into it a decent
amount
> in my line of work
I meant the ongoing documentation and implementation, not a fusebox app. A
fusebox app from last year would have those display header and footer
templates I disdain and a bunch of other stuff that has been improved
technique-wise.
> one group is just more honest than the other.
You client is only as honest as your attorney makes them :-P
> What I would take issue with is the idea that Fusebox is especially
> well-suited to n-tier applications, or especially well-suited to complex
> client interfaces. That's simply not the focus of Fusebox. Again, this
isn't
> a criticism of Fusebox - I'm not saying Fusebox is "bad". What I am saying
> is that it's not necessarily the best approach for everything, and that
> using Fusebox isn't going to be a panacea for developing complex web
> applications.
Actually, its n-tier capabilities is one reason I use it. You are basically
just plugging applications and their subapplications into each other.
> Admittedly, the above example could benefit from a better naming scheme in
> either case. Nevertheless, Fusebox in this case just provides an extra
level
> of abstraction, which doesn't benefit me.
No, you would still have to look at your frameset and then look at the pages
it calls so where is the abstraction?. The benefit is that the fusebox way
you write 3 lines of code in app_globals or application.cfm to lock all of
the templates down and you can dynamically change the frame by just changing
the fuseaction. As well, at a glance I could figure out what goes in those
frames and when.
> So's the material on the Fusebox site - at least the presentations.
There's
> Steve Nelson's paper, and something in French. And that's about it. Quoth
> Steve Nelson, 18 September:
Unfortunately the techniques on the fusebox site are not completely up to
date, but the docs do explain the frame work. I am pretty sure Steve, Gabe,
Hale, Nat et al are pretty busy with their real jobs and its probably hard
for them to take a month or two off and update the site. Most of this
information flows pretty redundantly on the [EMAIL PROTECTED] list
and Hal writes about it in CFDJ. However I don't find myself to be an
extraordinary super programmer, and I figured most of it out after reading
the fusebox docs and combing them with the CF DOCS.
> I'm not going to spend too much time researching something that we're not
> going to use, after I've already done the initial research. I stand by my
> claim that it's not for everybody (which is a pretty weak claim, after
all).
I initially researched CF 3.0. Decided there wasn't anything there that I
couldn't do in the languages I was using. When 4.0 came out last year, I
changed my mind and now use Coldfusion primarily. I think all recurring
methods or languages are worth investigation, but then I have that kind of
time on my hands.
I agree that if fusebox doesn't work for your application, use what does.
However I have yet to find a application that I could not or did not want to
code using its methods.
Sean Renet
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
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.
