← Back to team overview

gtg-contributors team mailing list archive

Re: Extended backend-fail signal

 

On Thu, Jan 9, 2014 at 5:21 PM, Parin Porecha <parinporecha@xxxxxxxxx> wrote:
> Thats a very nice addition to the backends service !
>
> I agree that we should not add backend specific error strings to
> backendsignals.py (ERRNO_BUGZILLA_*)
> Since it is meant to be a general class, can you please move those strings
> to the bugzilla backend ?
>

Sure.

Actually, all ERRNO_* in backendsignals.py should be removed, as well
as moving DBUS_MESSAGE, NETWORK_MESSAGE, and AUTHENTICATION_MESSAGE
out of custominfobar.py, after other backends are changed to pass
error message via the argument data. Because, ERRNO_* are used for
determining what message should be shown. Then, method set_error_code
will become more simple.

Regards,
Chenxiong Qi

>
>
> On Thu, Jan 9, 2014 at 2:14 PM, tkdchen <qcxhome@xxxxxxxxx> wrote:
>>
>> Hi folks,
>>
>> I have added the support of showing message in CustomInfoBar when
>> there is any problem due to invalid bug id. During the past
>> development, I found that current definition of backend-failed signal
>> and implementation of CustomInfoBar had a restriction. That is backend
>> author couldn't pass additional data except backend_id and error_no,
>> they are used to determine hard coded generic messages for DBus and
>> network in CustomInfoBar class definition. It blocked me to implement
>> the behavior I want.
>>
>> I extended the backend-failed signal and CustomInfoBar to overcome
>> this restriction and make set_error_no work well in threading.
>>
>> 1. Extend backend-failed signal definition
>>
>> I added additional argument named data[1] to backend-failed signal
>> definition and also added keyword argument data with default value
>> None to CustomeInfoBar.__init__. The argument data accepts a
>> dictionary object.
>>
>> With this small change, any backend author could pass backend-specific
>> data including message, and be more extensive to  CustomInfoBar do
>> more interesting things that needs more data from backend. In the
>> meanwhile, this change does not break other backends that use
>> CustomeInfoBar to show message.
>>
>> IMHO, defining backend-specific messages far from the backend is not a
>> good way. It'd better hand them to the backend author.
>>
>> 2. Synchronization of showing message in CustomInfoBar
>>
>> Due to backend_bugzilla.py syncs bug information in threading, make
>> on_backend_failed signal handler thread-safe[2]. This applies to any
>> other backends that works in threading.
>>
>> [1]
>> http://bazaar.launchpad.net/~qcxhome/gtg/bugzilla-sync-service/revision/1345/GTG/backends/backendsignals.py
>> [2]
>> http://bazaar.launchpad.net/~qcxhome/gtg/bugzilla-sync-service/revision/1345/GTG/gtk/browser/browser.py
>>
>> Regards,
>> Chenxiong Qi
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~gtg-contributors
>> Post to     : gtg-contributors@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~gtg-contributors
>> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> --
> Regards,
> Parin Porecha
>
> GTG Developer
> GNOME Foundation Member
> Github | Launchpad | Gnome Bugzilla | Ohloh



-- 
A Python developer living in Beijing
http://about.me


References