intentionally removed from FB4, because it's a Bad Thing (tm). The
non-runtime nature of FB4 is a good thing for a couple reasons:
1) it provides some primitive types of compile-time checking.
2) it forces you to clearly define the tasks (external or internal) that
make up the application's flow
2a) it utterly prevents such hackery as modifying the fusebox.fuseaction
variable inside the request, as was possible in FB3, and was never useful
for anything more than a crutch to avoid more complete planning and better
design (which isn't to say I'm not guilty ;)
Dynamic fuseactions (including the default fuseaction concept) go against
both those idea, for very small gain. The only benefit I can think of is
that you can change the fuseaction name within the circuit that is the
default, without having to change any external links of XFAs. You can
accomplish that by picking a fuseaction name that has "specialness", such as
'default', which is NEVER used for an actual fuseaction, but rather resides
at the top of your circuit and simple does a DO on whatever fuseaction you
deem to be the default.
If you're looking for backwards compatibilty, you can do that as well, in
your index.cfm file. When a compound fuseaction comes in with a zero-length
fuseaction name, set it to that same "special" fuseaction name, and away you
go.
Cheers,
barneyb
> -----Original Message-----
> From: Kenneth Wilson [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 17, 2004 6:03 PM
> To: CF-Talk
> Subject: RE: FB4 catching fusebox exceptions
>
> Any known plans for FB to add back the default fuseaction
> functionality from earlier days?
>
> Ken
>
> ________________________________
>
> From: Barney Boisvert [mailto:[EMAIL PROTECTED]
> Sent: Thu 6/17/2004 8:10 PM
> To: CF-Talk
> Subject: RE: FB4 catching fusebox exceptions
>
>
>
> Despite what people have said, FB4 is unable to catch
> exceptions arising
> from invalid circuits or fuseactions. This makes sense when
> you think about
> it, if you know how things work internally. A sample request
> goes like this
> (roughly):
>
> - Application.cfm runs
> - index.cfm runs and includes the runtime
> - the runtime does some preprocessing
> - the runtime calls the loader to load the XML files, if needed
> - the runtime passes the circuit and fuseaction name to the
> parser to build
> the parse file, if needed, and saves it to the 'parsed' directory
> - the runtime executes the parse file
> - the runtime returns to index.cfm
> - OnRequestEnd.cfm runs
>
> You can probably see the issue. The runtime needs to know
> the circuit and
> fuseaction to hand to the parser to generate the parse file.
> If it doesn't
> have valid info, it pukes, and generates the exception you
> included. Your
> processError plugin is rolled into the parse file, so it can
> only execute
> during actual request execution, which is far to late to catch invalid
> circuit and fuseaction exceptions.
>
> If you need to catch this type of exception (and you should),
> you have to do
> it with a CFTRY..CFCATCH in your index.cfm, or via a CFERROR
> tag, either in
> index.cfm or Application.cfm.
>
> Cheers,
> barneyb
>
> > -----Original Message-----
> > From: Michael T. Tangorre [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 17, 2004 4:54 PM
> > To: CF-Talk
> > Subject: FB4 catching fusebox exceptions
> >
> > In the processError phase I have a plugin called
> > "fuseboxExceptions". In
> > that file I have:
> >
> > <cfcatch type="fusebox">
> > <cfoutput>
> > <cfdump var="#cfcatch#" />
> > <cfabort>
> > </cfoutput>
> > </cfcatch>
> >
> > When I put in an invalid fuseaction in the URL it should get
> > caught and the
> > cfcatch structure should dump to the screen but instead I get
> > the standard
> > CF error page (below):
> >
> > "You specified a Fuseaction of junkVal which is not defined
> > in Circuit main.
> > "
> >
> > Can any FB4 people see my problem?
> >
> > Thanks,
> >
> > Mike
>
>
>
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
