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