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

>>>> 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.

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?

> >>> >>> 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.

> >> 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() { >>> >> >