It is actually interesting to see how much the decision to use or not
use custom tags affects how your application is constructed.
Custom tags have long allowed us to have something similar to a
function. Unfortunately, custom tags have some performance issues. These
performance issues are two fold. First, each call to a custom tag
requires creation of stack space and later deletion of that stack space
after the tag had finished executing. Second, all data passed through
the attributes scope is passed by value. This can be both a good thing
or a bad thing depending on how you look at it. From a performance point
of view passing data by value is always worse than passing by reference.
If you want to keep your application modular and not use custom tags
than you have a real problem. Using cfIncludes will allow you to have
modular code, but cfIncludes have namespace issues. This requires you to
create a stack to manage a local namespace. While managing a stack is
quite easy it requires a push() before the cfInclude and then a pop()
after the cfInclude is finished executing. There is immediately two
problems with this approach. First, I pointed out that a stack was a
performance problem for custom tags and then I went and suggested doing
the same thing. Bottom line is that you can't get around having a stack
to manage namespaces. However, there is a fundamental difference between
difference between creating a single stack and creating a stack for each
custom tag. The main difference being that my stack is only created and
destroyed once per request vs. creating and destroying a stack per
custom tag call. Second, implementing stack calls around all cfIncludes
sounds like a rather sucky kludge. This problem I can't solve unless the
gods at MM decide to allow includes from UDFs.
Interestingly enough using this stack kludge starts to have major
benefits in flexibility. It becomes hard to explain some of these
benefits because they become stack implementation specific. However, I
can say for fact that what started out as a kludge for the system here
at DevX has become more powerful than custom tags could have ever
been... without the performance penalties.
-Matt
-----Original Message-----
From: Shawn Regan [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 06, 2001 9:55 PM
To: CF_OpenSource
Subject: RE: Next Step
So I'm not looking to convince Matt, I just want to here more. And would
like to know what he does to combat the problems CF has (which he
believes
by saying CF has a real problem when it comes to custom tags, of course
this
is not quoted, but this is the impression I get from Matt.)
So off the topic off why we shouldn't use Fuse box for this project. I
personally would like to here from Matt what he does to over come the
problems we all put into our applications by using Fuse box or Cold
Fusion
in general? :)
-Shawn Regan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
