>Fusebox probably slightly reduces performance because every template is
>CFINCLUDEd within CFSWITCH/CFCASE logic in index.cfm, but I haven't gone
>to the trouble of measuring performance explicitly in two otherwise
>identical fusebox and non-fusebox applications so I don't know how much.
If you haven't done any testing, how do you even know if there is a hit?
First of all this is a use case scenerio. For example, if you are using any
sort of decision logic for your forms, you are going to have to have an IF
statement somewhere, CFSWITCH out performs CFIF 8 days a week. Now I am sure
you can come up with a scenerio where a fusebox application is out performed
by the same application written differently. But either way, this miniscule
minisecond hit is not close to an argument for or against fusebox. The
problem I have with the nay sayers is that you make broad stroke statements
like NON FUSEBOX OUT PERFORMS FUSEBOX. This is not always the case, and the
performance difference is too small to reckon. My clients to not pay me for
miniseconds, they pay me for complex, scalable web application solutions. If
I lose 100 miliseconds site wide, and my site is completed faster with the
same proffession craftsmanship used by non fusebox programmes, I think I am
still going to collect my check. I should point out here I am in it for the
money :-P. In my not so humble opinion the best thing about the index page
is that it takes me 3 lines of code to lock done ALL of my templates. I
would like to see the same thing done using a non fusebox methodology, so if
I lose performance on the include, I gain it not having a monolithic
application.cfm
>The thing I like least about the fusebox specification is the really
>stupid filenaming system which scatters related modules away from each
>other in a directory view (qryCustomerInfo.cfm and qryPrecincts.cfm are
>not likely to be related except by their general function of containing
>queries; it's far more helpful to name templates by functional groups
>like CustomerList.cfm, CustomerEdit.cfm, and CustomerUpdate.cfm).
First of all, if a filenaming system is coherent and logical I don't think
it can be called stupid. Anyone that reads the docs and then looks at a
file with qry_ in front of it knows right away that is a query file.
Secondly, I am guessing you think that all the qry_ files go into a /qry
folder. Well here is some good news for you, they don't have too. My
applications are broken into subapplications and the sub applications do
have have folders for each file type, however they are specific to the
subapplication (or modules). The purpose for this is directory readability.
Because I never attended Elen Wood's Speed Reading Class, this makes it
easier for me to find a specific file type faster than googling down an
unstructured file system. So, all modules are separated by function and each
use this stupid file naming system. For us morons it makes it easier to
read.
>For small applications (perhaps two dozen templates or fewer) there's no
advantage I can see
Well for one thing, when Greenspan/Wallstreet closes all the DOT GONES you
are going to find clients that want small applications that they gradually
build on to because they are not getting anymore IPO money. In these cases,
fusebox's methodology allows a ready made solution to just plug things in.
>This is a fairly broad generalization. How do you know that we haven't
read
>the documentation or researched its implementation? This is beginning to
>turn into a "If you don't use Fusebox, you must obviously suck as a CF
>programmer" kind of debate,
AND
>I'd hazard a guess that you have no idea how much experience some of us
have
>in ColdFusion.
First of all, I NEVER said that people that do not use fusebox cannot
program. I know its an election year, and on TV you are seeing a lot of
things taken out of context used as reference material, but lets try to keep
what I say in the context of how I say it. My response here was to all of
the people that say "You can't do this in fusebox". This is just not the
case. All of the examples "why not to" use fusebox where examples of people
that do not use fusebox. Using fusebox does not mean "I used it a few
times". Any programming methodology has continual evolution. Most of these
reasons why not to use fusebox were based on documentation that is outdated.
However like I said in my response to Dave, I do not find myself to be
extraordinary, and if I can figure out a fusebox solution, there must be an
easy one. So, I looked at those examples of why not to use fusebox and
retorted yes, you can do that in fusebox, because I do do that in fusebox.
Again, Does anyone have any real problems that cannot be solved in fusebox?
The reason I ask, is because if there is something drastically wrong with it
or something that cannot be done using it besides miniscual performance
hits, I would like to know so I can change what I am doing. So far no one
has presented such an example. The examples given are not disimilar to the
ones given by ASP programmers that site reasons why not to use CF. The
reality is, that they may have played around in CF, but do not program in it
day in and day out.
Secondly, I think in my first response to Dave I said I agreed it was "A"
methodology and not "THE" methodology.
Fusebox is a FRAMEWORK methodology. Anything you can do in CF you can do in
Fusebox. I find it faster to program in. The reason I do not program
Broadvision anymore is that I find CF way more on the rapid development time
side of programming. And I can only speak empirically here, but once I got
my arms around fusebox I, ME, Sean Renet, programmed CF faster. And as an
employer of subcontracters I find the contract work I let out that is done
in fusebox is returned faster than when it is written otherwise. Now to save
you all some typing, Faster does mean better when the craftsmanship is
equal. If you think otherwise, I would love to program for you so I can
spend way more time on the beach, we have 12 foot swells and I am missing
them so I can defend what I find to be a well thought out, ever developing
methodology
>and Fusebox is definately NOT OO..
Which part of fusebox is not object oriented? Have you ever built a porn or
financial site? Try doing it without being object oriented. It can't be
done. Well I suppose it can if your intent is programming for your friends
and family. Fusebox is neither object oriented or not object oriented, you
can program in it either way. Again, its a framework methodology that uses
a standard naming structure.
>My opinon is object oriented programming done properly, and iwth the proper
environment (think Java) It is a >dream
I am guessing that by this you mean Java and CF should be programmed
differently. The two are married. IMNSHO any heavy lifting should be done
server side.
------------------------------------------------------------------------------
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.
