Just a coulpe of comments :)
No matter what, even with logical ordering of
your CFSWITCH, it is going to slow it down
somewhat and the bigger your switch statement
the longer it takes to test each.
Having read GCC source code, to see how
the switch statement in C is made more
effecient, it just guts the if statement
and makes it more 'fit and trim' so to
speak, which is I am sure what the alliare
folks do. It just runs through a list of
cases until it finds the case its looking
for, instead of performing a lot of
logic and parsing. Sorry for less details
here but thats the gist of it. But.. I
agree most people are mislead in believing
its a really big performance hit... But it
is a hit.
>From a strictly technical and programming stand
point Fusebox is NOT object oriented period.
It does not adhere to any part of object oriented
methodology or terminiology. There is no way to
invoke a method, I can "call a fuse" but that is
NOT a method and fusebox does not do "encapsulation"
at all. Data hiding wherezitat? You can argue
about this all day, and in practice it may emulate
mostly what object oriented programming gives you
but not all of the way, and if you do want it to
be 'object oriented' there is nothing to enforce
this integrity. I was not making a 'broad'
assumption, I was stating a fact, FuseBox is
not object oriented by itself nor you (strictly)
achieve the same effects as OO in say C++ or Java.
Speaking in OO terms objects communicate via
messaging. You send an object a message it does
something amd possibly returns a result never
allowing you to outright touch the data hence
the data is hidden from you.
I really really think its going a bit far to say
that this is how fusebox operates at the theory
level or any level of abstraction for what Fusebox
does.
How high level are you looking at it determines how
'object oriented' anything is.
I have written plenty of C++ applications (C++
does a evil job at implmenting OO also, at least
it is all there however) and following Fusebox's
convnetions does NOT lead to anything like
object oriented programming.
OO programming requires a totally different mind
frame than procedural programming, and if you
think OO, your code is OO. There are a couple
of CF tags for implmenting objects, these do
more along the lines of defining classes than
Fusebox ever will.
And anything can be done.. obviosuly. What
do you think there was before CF LONG before
CF there was C, which is a procedural language.
There are plenty of financial institutions that
still run on their C programs...
Some people actually prefer keeping things
procedural... Hence I have seen several
financial type sites written in perl which
has classes but I highly doubt they used
them on this site. Its all a matter of
preference and the fact that people throw
around far to many buzz words and it annoys
me when everyone tries to classify stuff as
something it just plain isnt.
Fusebox IS NOT object oriented. You can
emulate object oriented thinking in your
code even in C, but its MUCH easier with
actual facilities for defining classes
and creating actual objects that behave
how
Please please, dont ask vague questions like
"Have you built a porn or financial site"
its kind of condescending and elitist to
assume if someone has not done something
there is no way they can grasp it.
CFML, is not in any way like Stand Alone java
applications. EJB can be plugged into and used
for logic easily enough, but CFML is a far cry
from being "married" to Java just yet.
JSP is married to Java, CF is not... (yet)
Again, how can I create objects and program
and treat my coldfusion templates like objects
im not being obstinante since I know the answer
to this, but
CFML is procedural, any way you slice it its not
all neat and tightly packed in and Fusebox generally
does not as neatly encapsulate and and work like
OO programming, I definately know im not alone
with this opinon, A close friend of mine who has
been a fan of OO longer than I have been programming
has worked in "purely OO" languages such as
smalltalk where.. EVERYTIHNG is an object, and
he has worked with some CF and any way you slice it
its not OO. I am speaking in terms of strictly OO
go grab a good book on PURE OO theory and you will
see where Fusebox is NOT OO.
Jeremy Allen
[EMAIL PROTECTED]
-----Original Message-----
From: Sean Renet [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 20, 2000 9:15 PM
To: CF-Talk
Subject: Re: Fusebox [CF-Talk]--- Wow
>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/[email protected]/
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.
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
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.
