> Hi Paul,
>
> Currently Fusion actually fires an error event.
> Fusion.js:
> if (r.status >= 400) {
> Fusion.reportError(new Fusion.Error(Fusion.Error.FATAL,
> 'xml2json: invalid XML document: ' + r.statusText
> + " : " + r.request.url));
> return;
> }
> This will fire an error event, and the event is registered in
> MapGuide.
> MapGuide template:
> Fusion.registerForEvent(Fusion.Event.FUSION_ERROR, fusionError);
>
> var fusionError = function(eventId, error) {
> alert('Fusion Error: \n' + error.toString());
> }
> In this way, I can handle the error message in MapGuide template,
> parse them and only show the exception message. This solution will
> not affect fusion. How do you like this idea?
>
> Thanks & regards,
> Christine
>
> -----Original Message-----
> From: Paul Spencer [mailto:
[hidden email]]
> Sent: Tuesday, July 21, 2009 3:27 AM
> To: Jason Birch
> Cc: Christine Bao;
[hidden email]
> Subject: Re: Ticket: Fusion reports unreadable error message
>
> This sounds more application-specific than I am willing to put into
> the library as core functionality. So to accommodate this, I would
> prefer that we expose 'extended' error conditions through event
> notifications that developers can use to implement their own handling
> system. In this case, Fusion would never alert an error but rather
> would trigger error events (some of this happens already) and pass
> both basic and extended information.
>
> In this case, Christine's patch should be modified to fire an error
> event instead of an alert. Perhaps that is beyond the scope of the
> current change :)
>
> Paul
>
> On 20-Jul-09, at 2:13 PM, Jason Birch wrote:
>
>> I'm not sure. I was initially going to suggest that, but I often
>> don't get trouble reports until after an application has been signed
>> off, moved to production, etc... I'd hate to leave a debug flag
>> turned on in production if it had performance implications made the
>> interface totally developer-centric, and I'd be concerned that
>> calling the config option "debug" would lead to this.
>>
>> If it was called "extendedErrors" or something like that it might be
>> better? Or if there were different debug levels (none, error,
>> information)?
>>
>> Another option would be a link that says "Email Problem Report"
>> where user can fill in information about what they were doing, and
>> all debug info is automatically added to the report. :)
>>
>> Jason
>>
>> -----Original Message-----
>> From: Paul Spencer
>> Sent: Monday, July 20, 2009 10:56 AM
>> Subject: Re: Ticket: Fusion reports unreadable error message
>>
>> Would a configurable option to run in 'debug' mode vs production mode
>> be practical for this sort of this? It could be added to the
>> existing
>> config.json and used in various places for reporting problems vs
>> either suppressing them or providing less ominous looking errors ...
>>
>> Paul
>
>
> __________________________________________
>
> Paul Spencer
> Chief Technology Officer
> DM Solutions Group Inc
>
http://research.dmsolutions.ca/>
