What I'm doing is a few things. The first is tracing through the debug
modules and removing things that are just not used. After that, I'm
cleaning up the logic some. Then I'm getting more information for the
debug, but limited to what information comes from the factory.
Finally, I'm threading all the templates called in a page in CFTREE.
This will include cfincludes, modules and CFCs. It's all for better
debugging. I'm not going to go outside of that limited field yet.
When I'm done, anyone can take the template and use it with a file
scanner to get more specific file data.
I just needed to see all the templates in a single pare run, what
called what and where. That's all available through the factory.
On Jul 15, 2004, at 7:44 PM, Michael Dinowitz wrote:
> Well, I've decided that the best thing for me to do is to rewrite the
> debugging template to my specifications.
> Holy hell in a hand backet Batman!
Wha's a hand backet?
Are you going to write a source-code analyzer or a runtime-trace?
If the latter, you might consider accepting hints from the various
modules as they execute. I did this in some complex code I wrote and I
think that FB did something like this in one of their implementations.
All I did was have a simple variable that I set in each routine--
something like:
<cfif Application.doTrace><cfset trace = "module MyModuleName, line no
nnn"><cfoutput>Trace...#trace#]</cfoutput></cfif>
I would paste this at the front of any line I wanted to watch ( at
least template entry & exit points)
I could turn trace on or off interactively.
You could do this by logging instead of tracing.
Anyway, this helped me quickly isolate any problem areas, then focus,
in more detail, by adding more tracepoints,
At the time CF didn't have any such facility. And I found it very
useful in determining application flow when it depended on external
events such as CC auth, or CFHttp requests.
Dick________________________________
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
