[Kimchi-devel] [PATCH] [WoK] Asynchronous UI notification implementation

[Aline Manera]

>>>>>       var initUI = function() {
>>>>> diff --git a/ui/js/wok.user-log.js b/ui/js/wok.user-log.js
>>>>> index 0e8fb09..083b6c3 100644
>>>>> --- a/ui/js/wok.user-log.js
>>>>> +++ b/ui/js/wok.user-log.js
>>>>> @@ -153,6 +153,12 @@ wok.initUserLogContent = function() {
>>>>>           $("#user-log-grid").bootgrid("search");
>>>>>           wok.initUserLogConfigGridData();
>>>>>       });
>>>>> +
>>>>
>>>>> + wok.addNotificationListener('userlog', function(message) {
>>>>> +        if (message === 'new_log_entry') {
>>>>> +            $("#refresh-button").click();
>>>>> +        }
>>>>> +    });
>>>>
>>>> Backend is sending a notification with 'new_log_entry' and you are 
>>>> registering a notification for 'userlog'.
>>>> How is it working?
>>>
>>> 'userlog' is the identifier of the listener that will be used in the 
>>> hash
>>> wok.notificationListeners.
>>>
>>
>> Where does the backend make reference to it? On backend, I am only 
>> seeing the message as 'new_log_entry'. How does the UI assumes 
>> 'userlog' as the identifier?
>
> There is no connection to the backend. This is simply an listener 
> identifier of the
> tab "user log". It is an UI information only.
>
> The backend can send the information in the format we've discussed. 
> the UI can
> name its event listener freely. Or course we can standardize the name. 
> Perhaps
> using the tab_id or something.
>

Why do we need a second identifier? Why isn't the message id 
(new_log_entry) enough?

> Do you want me to split this contribution in two patches, one for 
> backend and
> other for frontend, to make it clearer what is backend or frontend 
> only code?
>
>

It is up to you. I am only trying to understand the whole flow.

>
>>
>>>>
>>>> Shouldn't the 'name' required by addNotificationListener be 
>>>> 'new_log_entry'? So wok would be redirect to the function 
>>>> automatically?
>>>> Why do you need to distinguish the 'new_log_entry' later?
>>>>
>>>> Also, we will need to create a pattern message for notification to 
>>>> avoid having a plugin overwriting a notification from another plugin.
>>>
>>> Agree. I was aware that this 'new_log_entry' was going to be changed by
>>> something more formal.
>>>
>>>>
>>>> That said, my suggestion is: <plugin>_<resource>_<action> which 
>>>> will result in something like:
>>>>
>>>> wok_log_create
>>>> kimchi_vms_create
>>>> kimchi_vm_update
>>>> kimchi_vm_start
>>>> ginger_backups_create
>>>> ginger_backup_restore
>>>>
>>>> and so on.
>>>>
>>>> That way, we can automatically add the notification on 
>>>> control/base.py which will work for everyone. And then, the plugin 
>>>> just need to register the listener on UI.
>>>> Something like:
>>>>
>>>> @model/base.py
>>>> #Collection.index and Resource.index (need to cover both)
>>>> def index(...):
>>>> (...)
>>>>     # on sucsess
>>>>     notification = "%s_%s_%s" % (plugin_name, resource/collection, 
>>>> action)
>>>>     send_websocket_notification(notification)
>>>>
>>>> def _generate_action_handler_base(...):
>>>>     (...)
>>>>     # on success
>>>>     notification = "%s_%s_%s" % (plugin_name, resource/collection, 
>>>> action)
>>>>     send_websocket_notification(notification)
>>>>
>>>> What do you think?
>>>
>>> I think we can work with this plugin_name/entity/action format, 
>>> perhaps adding
>>> an 'args' field to it. 
>>
>> Which 'args'?
>
> For example, /ginger/Users/create. Which user was created? This is 
> something we would
> like to inform too.
>

Really? Why?

On an notification received the UI will refresh the whole page. I don't 
think knowing the user will make difference.

>>
>>> In the case of this patch we would have 'wok/userlog/create'
>>> or something similar.
>>>
>>> We need to also consider task handling in this context. We can 
>>> change the default
>>> success/failure handles to also automatically report the status to 
>>> the UI via
>>> websocket.
>>>
>>
>> It already exists today for the user log.
>> So we just need to link the log_request() to the 
>> send_notification_message() and we are all covered.
>>
>>> In fact, we need to consider a lot of standardization with this 
>>> feature. For this patch,
>>> I we can start by doing the action handler changes you've proposed 
>>> to implement the
>>> user log changes. I have no problems putting the notification under 
>>> the 'index' of
>>> both Collection and Resource models too.
>>>
>>>
>>> Daniel
>>>>
>>>>>   };
>>>>>
>>>>>   wok.initUserLogWindow = function() {
>>>>
>>>
>>
>