[fusion-dev] Re: Ticket: Fusion reports unreadable error message

[Paul Spencer]

Excellent!

On 20-Jul-09, at 10:22 PM, Christine Bao wrote:

> 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:pspencer at dmsolutions.ca]
> Sent: Tuesday, July 21, 2009 3:27 AM
> To: Jason Birch
> Cc: Christine Bao; fusion-dev at lists.osgeo.org
> 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/
>


__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://research.dmsolutions.ca/