Well, I think that while that's typically a good idea (not to have HTML in
act files), it surely shouldn't be a hard, fast, and unbreakable rule. If it
makes sense to put error messages in your act files, I'd go ahead and do it.
Hal Helms
Team Allaire
[ See www.halhelms.com <http://www.halhelms.com> for info on training
classes ]
-----Original Message-----
From: Gary Morin [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 16, 2001 3:40 PM
To: Fusebox
Subject: RE: Error Handling
I'm quite happen with the idea of the 'bubble error checking', minor
problems can be dealt with in the local circuit, and major errors may cause
the application circuit to be refreshed.
My question is more about where and how you prompt the user about the error
( error may be too strong of term in many cases). Image if a user select X
number of items on a page and presses submit.
On the act_validate page, the number items selected is compared to the
number items allowed for the user, if too many items have been selected the
user is informed and asked to reselect. I know there are many ways to do
this, it would simple to just prompt the user in the act_validate box and
use XFA to return to the select page. But in all the Fusebox rules I see, it
states, chiselled in stone, 'thou shall not do HTML in act_ files' but it
seems over the top to me to use dsp_message tag/page or use an error message
fuse.
Comments?
Cheers
Gary
-----Original Message-----
From: Hal Helms [mailto:[EMAIL PROTECTED]]
Sent: 16 April 2001 19:04
To: Fusebox
Subject: RE: Error Handling
Gary,
I usually decide upfront what kinds of errors I want to be implemented from
a site-wide perspective. Typically, any information sent to the user, I let
bubble up to the app level and catch it there. This keeps everything
uniform. Exceptions that are really speciific to the fuse or that circuit I
catch there. For example, at Rooms To Go, if the credit card processing
company (RTG's private card) can't authorize a new applicant right away, we
catch the exception and I put it into a table for scheduled reprocessing.
This is the sort of exception that is specific to that particular code and
which I would want to catch at that level. But if I wanted to communicate
with the user over that, I would rethrow an error from within my first
<cftry><cfcatch> tags. Hope that's not completely muddy...
I agree with Steve about having all the error messages logged. I have a
small custom tag that writes to a text file. You could also have it email
you, etc.
Hal Helms
Team Allaire
[ See www.halhelms.com <http://www.halhelms.com> for info on training
classes ]
-----Original Message-----
From: Gary Morin [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 16, 2001 1:06 PM
To: Fusebox
Subject: Error Handling
Hi All
I'm just about to start implementing error handling in XFB application, I
will probably implement code similar to Hal Helms nested error handling
code.
Often errors are generated/captured in act_ pages, from the user perspective
a polite message informing him of the error and requesting to do the
appropriate action to correct the problem, this action may be refreshing the
page, or doing a login etc. Cftry and Cfcatch will be used to handle the
errors
My question is what is the excepted way to notify the problem to the user?
In some examples, including Hal's, HTML messages are placed directly in the
act file or even in the index.cfm, if the nested error handling code is
used. Or should I use an 'Error fuse' to display and error message and use
a XFA to return the user to the appropriate position to continue( this would
also require all variables to be passed through the error handling code).
So how do others handle simple errors and informing users?
Cheers
Gary
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
