John,
You typed very big letter. Thank you for it.
But I'm about other thing
Do you see in the third example following text:
The variable "attributes.fuseaction" is not available or the Fusebox
framework could not find the circuit you requested: "". If you think
this error is incorrect, turn off the Fusebox suppress error messages
flag by setting fusebox.SuppressErrors to FALSE, and you will receive
ColdFusion's "normal" error output.
As far as you can download that application try to change
fusebox.SuppressErrors flag trying to avoid displaying/hiding that
message.
Do you see that in the second example you don't see that message,
but in the third one you do. Why? :-)
Thursday, June 6, 2002, 7:30:51 PM, you wrote:
John> Alex,
John> now that you've made your example clear by providing examples of the problem
John> (rather than posting the core file), it's fairly straightforward to see the
John> error.
John> In the first example (as expected) everything is alright.
John> In the second example, you are referencing a circuit which does not exist.
John> The official core file does not define what to do for undefined circuits --
John> that is not a bug at all, it is a short-coming in the implicit
John> specification. It's actually a *user* error for calling a undefined
John> circuit -- the fact that the core file ends up barfing on it only serves to
John> show that the developer would need to (a) remove typos from the URLs, or (b)
John> pre-process the fuseaction or (c) use one of several other solutions
John> published on the process (for example, the Techspedition core file catches
John> undefined circuits and throws them up to the "home" circuit for handling --
John> however this doesn't have to be done via a core file, obviously).
John> One thing you should be able to do, although not with the official core file
John> version 3.01, is to compare "fusebox.circuit" with "fusebox.targetcircuit",
John> which would only have differing values in the situation you describe of an
John> non-existing or ill-defined circuit. This test is not necessary in the core
John> file itself, but it is necessary for the core file to set appropriate values
John> for those two API variables (right now targetcircuit is always set to
John> circuit whereas it should have a single conditional applied to it wherein it
John> is set to circuit only after a successful 'does "circuit" exist?'
John> conditional). That is a known problem.
John> In your third example, a empty string fuseaction, again it is not the core
John> file's problem at all. The implicit spec just doesn't define what to do with
John> a fuseaction that has no value. However, the purpose of the fbx_settings
John> file is to set values and if you follow the common practice to put a
John> <cfparam name="attributes.fuseaction" default="corefilestest1.welcome">
John> in your top-level fbx_settings file then you wouldn't encounter this error.
John> (there are two other such solutions as well -- you can put this above line
John> in the "index.cfm" before the core is even called, or alternately you can
John> make use of the literal fuseaction ".defaultfuseaction".)
John> you'd also asked:
>> Sorry. I didn't understand you thought of using third party
>> solutions for error handling. Why I need to use them if I
>> can make my one in a minute or two?
John> well there are a number of reasons for that. The errors above would have
John> been caught by any trivial error handler, but the real issue is
John> distinguishing between outright errors in the core file (such as the
John> discrepancy between "fusebox.circuit" and "fusebox.targetcircuit") versus
John> errors that occur due to developer mistake or oversight which are only
John> caught later on in the core file (such as that same example). The fact that
John> the error doesn't manifest itself until line X, doesn't mean there is a
John> problem with the core file *at* line X. And, in your third example where you
John> didn't have a default fuseaction defined, that also is not something "wrong"
John> with the corefile at line X; all of the FB3 documentation clearly states how
John> to handle a "default" fuseaction.
John> There is a good argument for having NO error handling of any type in the
John> core file -- just throw the darn error and let the developer deal with it --
John> as long as a mechanism for identifying the actual source of the error can be
John> found. [Again, I'm not talking about bugs in the core but rather in errors
John> that occur simply during the core file's execution when operating on
John> developers' code.]
John> The third party solutions currently come in two flavors. If you use FEX,
John> then that focuses directly on error handling and one uses a modified core
John> file. If you use Techspedition's FuseQ, then that too uses a modified core
John> file but not for error handling -- the error handling is just one of many
John> solutions that derive from it, some others being bubbling of the error
John> handling, layout fuses, component content, locating circuits anywhere on the
John> physical drive (not just "beneath" the root) and a very easy transition to
John> the Model-View-Controller design pattern popular in the Java world.
John> Either way, the point is that the core file itself needs to be fairly tight
John> and constrained. The larger it is, the more has to be made
John> backwardly-compatible and the more "fragile" it is moving forward. You can
John> most certainly "roll-your-own" error handling but I suspect that it will
John> have to be fairly limited in scope within the constraints of the official
John> core file. That is, it may only take, as you say, a "minute or two" to
John> create an error handler for one particular problem but I feel pretty
John> confident that it would take way more than a minute to conceive and
John> implement a general error handling solution, something more substantial than
John> wrapping the core file in a cftry/cfcatch.. That part is up to you, though.
John> You can always write your own core file, but then you'd be up against the
John> maintenance and compatibility issues which may or may not be something you
John> want. And it also inhibits one's ability to get help with various issues in
John> the public forum since others will not be familiar with the extensive nature
John> of a private core file and would have little incentive for climbing that
John> learning curve to get to the point where they could help you with what is a
John> non-general solution.
John> Going down the custom core file road is a decision each developer has to
John> make on their own. It sounds fun but it's actually a big pain in the butt.
John> My suggestion is that if you're modifying the core file to solve a specific
John> solution by then you're doing it for the wrong reason -- that is "coding by
John> exception" -- and it is often characterized by a series of <CFIF>s. If what
John> you modify solves the specific solution as part of a generalized problem
John> topology, which is manifested by other, unexpected solutions that flow
John> naturally out of it, then it's worth pursuing in some form, either on your
John> own or in working with the authors of one of the core files.
John> ----- Original Message -----
John> From: "Alex Puritche" <[EMAIL PROTECTED]>
John> To: <[EMAIL PROTECTED]>
John> Sent: Thursday, June 06, 2002 5:37 AM
John> Subject: Re[2]: Bug in core files?
>> John,
>>
>> I'm not going to post any kind of "live" urls.
>> I use standard fusebox files. I mean I used them before
>> yesterday. I'm not sure that screenshots I already posted don't
>> make sense about the problem. It is definitely a bug, and must be
>> fixed in future builds of FB core files.
>> But I wrote sample application.
>> http://www.new.iname.md/reader/fb/fbtest1/
>> I hope it will eliminate all misunderstandings. :-)
>>
>> Sorry. I didn't understand you thought of using third party
>> solutions for error handling. Why I need to use them if I
>> can make my one in a minute or two?
>>
>> Another issue coming soon. ;-)
>>
>>
>> Thursday, June 6, 2002, 3:17:53 AM, you wrote:
>>
>> John> Hi Alex,
>>
>> John> I'm not sure that really points out any problems at all, there are a
John> number
>> John> of things that a developer can set up wrong which the core files
John> don't end
>> John> up catching the error correctly. While that points to the need for
John> better
>> John> error *handling* with the core files (something you can get
John> immediately by
>> John> using either the Techspedition or the FEX unofficial solutions,
John> available at
>> John> www.techspedition.com or www.fusiam.com, respectfully), it doesn't
John> really
>> John> clear up where the problem is coming from. Can you give us an online
John> URL
>> John> along with some of your own code ("I tried to log in with fuseaction
>> John> "users.login" and it threw an error!" or stuff like that) so that we
John> can
>> John> first determine if you're doing "standard" Fusebox? Otherwise we
John> may well
>> John> spend multiple man-hours tracking down the problem only to find out
John> it had
>> John> nothing to do with the core file -- other than in CATCHing the
John> error.
>>
>> John> Of course, that is the nice thing about using standardized core
John> files -- you
>> John> get a much larger group of people who can potentially help you catch
John> your
>> John> bug because they don't have the learning curve of wondering how your
John> core
>> John> file works -- cuz it's one of the standard ones! :) SO more people
John> having
>> John> to use less effort to stomp your bug means a greater likelihood that
John> you'll
>> John> get help fast.
>>
>>
>>
>>
>> John> ----- Original Message -----
>> John> From: "Alex Puritche" <[EMAIL PROTECTED]>
>> John> To: <[EMAIL PROTECTED]>
>> John> Sent: Wednesday, June 05, 2002 5:54 PM
>> John> Subject: Bug in core files?
>>
>>
>> >> Hi, folks!
>> >> Several urls :-)
>> >>
>> >> http://www.new.iname.md/reader/fb/was.png
>> >> http://www.new.iname.md/reader/fb/now.png
>> >>
>> >> Can somebody explain me what happening? Do I use "old" set of core
>> >> files? Or is it just a bug?
>> >>
>> >> Explanation for those who can't dig in...
>> >> fusebox.suppressErrors flag won't work for the "SECTION EIGHT" because
>> >> this section don't handle it.
>> >>
>> >> Several other issues coming soon. :-)
>> >>
>> >>
>> >> --
>> >> Regards,
>> >> Alex mailto:[EMAIL PROTECTED]
>> >>
>> >>
>>
>>
>>
>> --
>> Regards,
>> Alex mailto:[EMAIL PROTECTED]
>>
>>
--
Regards,
Alex mailto:[EMAIL PROTECTED]
May all your Internet Dreams come true!
http://www.intellinetinteractive.com/
==^================================================================
This email was sent to: [email protected]
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9
Or send an email to: [EMAIL PROTECTED]
T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================
