<cfif fileExists(ExpandPath(action & ".cfm"))>
<cfinclude template="#action#.cfm">
</cfif>
Nice idea, Isaac... So the above ExpandPath
function assumes my processing templates
are in the same directory as the display page?
If so, what how would the code change if I put
my processing templates in directory called
"processing" and my display pages were in the
"html" directory?
(Showing my ignorance about the ExpandPath
function...haven't used it...familiar with it, but
not in depth...)
Rick
> -----Original Message-----
> From: S. Isaac Dealey [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 07, 2006 11:02 AM
> To: CF-Talk
> Subject: RE: OOP, why me?
>
>
> > However, I will say that I have recently attempted
> > to put all my processing in a template and use
> > CFSWITCH / CFCASE to process info because
> > I wanted the user to stay on the same page of
> > an app (an attempt to emulate desktop software)
> > for working, even though it required trips back and
> > forth to the server/database. Keeping things visually
> > simple is key for this client and I wanted to avoid
> > changing pages as often as possible.
>
> > So there is a lot of links with ?Action= attached to
> > them and sent to a main processing template where
> > processing was done according to the definition
> > of Action...
>
> > While it was simple to know where all the processing
> > queries were located, that page was beginning to become
> > a bear to maintain and track what was going on. I found
> > thee was something to be said for keeping the processes
> > attached to their relevant displays when they process only
> > affected on particular display...
>
> Here's another alternative for you:
>
> <cfif fileExists(ExpandPath(action & ".cfm"))>
> <cfinclude template="#action#.cfm">
> </cfif>
>
> Then put the contents of each of your case statements into a file with
> the same name as your action value -- that would break up your page so
> it's not such a bear to work with.
>
> CF7's stack trace is pretty nice for telling you where errors are
> happening... I use a lot of nested code where an error frequently
> occurs in a CFC method, called from several other CFC methods leading
> back up to an included template. With robust exceptions turned on in
> the CF Administrator I usually get a nice list of which methods were
> being called when the error happened. Usually the problem isn't in the
> last template, it's usually somewhere further up the chain where I
> provided bad information to one of my CFCs, so I scroll down to the
> 4th or 5th template in the list and it's pretty easy for me to fix
> once I get there.
>
> (Although the display of processing times for templates in debug
> output is HUGE. I'd print it out, but I'd need a larger room to put it
> in... like... Wyoming.)
>
>
> s. isaac dealey 434.293.6201
> new epoch : isn't it time for a change?
>
> add features without fixtures with
> the onTap open source framework
>
> http://www.fusiontap.com
> http://coldfusion.sys-con.com/author/4806Dealey.htm
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:234455
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
