[yast-devel] Showing state of WebYaST plugins in status plugin.
Hi,
currently we have two requests for showing special states of WebYaST
plugins in the
status plugin:
Mail Settings:
When the user has submitted a test mail he will be asked in the status
module,
if he has received the email. This message disappears after he has
confirmed the receive
in the status module.
Registration:
A warning will be displayed in the status module if the user has skipped
over the registration.
This warning disappears only after the user has successfully finished
the registration.
I believe that we will have more such requests in the future. So we
should think about
a generic solution. One proposal would be:
Webservice side:
The status module checks each installed plugin if it has an interface
"status"
like:
registration/registration/status [GET|POST]
[GET| returns:
<states>
<state>
<level>info|warning|error</level>
On Monday 22 of March 2010 12:10:33 Stefan Schubert wrote:
Hi, currently we have two requests for showing special states of WebYaST plugins in the status plugin:
Mail Settings: When the user has submitted a test mail he will be asked in the status module, if he has received the email. This message disappears after he has confirmed the receive in the status module.
Registration: A warning will be displayed in the status module if the user has skipped over the registration. This warning disappears only after the user has successfully finished the registration.
I believe that we will have more such requests in the future. So we should think about a generic solution. One proposal would be:
Webservice side: The status module checks each installed plugin if it has an interface "status"
like: registration/registration/status [GET|POST]
[GET| returns:
<states> <state> <level>info|warning|error</level>
id-string .... ... true|false </state> <state> .... </state> </states>So each plugin can return more than one message. The "level" will be displayed in the status module. "*_description" is a English default description which will be displayed if there is no translation on the WebYaST client side available. "message_id" indicates the translated message in the WebYaST client status module. If the user press the "confirm_button" a POST request will be send to the concerning service plugin. Then it is up to the service plugin to reset the state.
Where do you get the translated text, if the status command is purely rest-based? Or are we going to translate messages from rest services as well? Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Am 22.03.2010 12:55, schrieb Jiří Suchomel:
On Monday 22 of March 2010 12:10:33 Stefan Schubert wrote:
Hi, currently we have two requests for showing special states of WebYaST plugins in the status plugin:
Mail Settings: When the user has submitted a test mail he will be asked in the status module, if he has received the email. This message disappears after he has confirmed the receive in the status module.
Registration: A warning will be displayed in the status module if the user has skipped over the registration. This warning disappears only after the user has successfully finished the registration.
I believe that we will have more such requests in the future. So we should think about a generic solution. One proposal would be:
Webservice side: The status module checks each installed plugin if it has an interface "status"
like: registration/registration/status [GET|POST]
[GET| returns:
<states> <state> <level>info|warning|error</level>
id-string .... ... true|false </state> <state> .... </state> </states>So each plugin can return more than one message. The "level" will be displayed in the status module. "*_description" is a English default description which will be displayed if there is no translation on the WebYaST client side available. "message_id" indicates the translated message in the WebYaST client status module. If the user press the "confirm_button" a POST request will be send to the concerning service plugin. Then it is up to the service plugin to reset the state.
Where do you get the translated text, if the status command is purely rest-based? Or are we going to translate messages from rest services as well?
As long as we do not have any translation mechanism (e.g. language information in the REST request) we will have to provide the translation in the webclient status module. Thats why I have suggested also a "message_id". Greetings Stefan
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Stefan Schubert write:
Hi, currently we have two requests for showing special states of WebYaST plugins in the status plugin:
Mail Settings: When the user has submitted a test mail he will be asked in the status module, if he has received the email. This message disappears after he has confirmed the receive in the status module.
Registration: A warning will be displayed in the status module if the user has skipped over the registration. This warning disappears only after the user has successfully finished the registration.
I believe that we will have more such requests in the future. So we should think about a generic solution. One proposal would be:
Webservice side: The status module checks each installed plugin if it has an interface "status"
like: registration/registration/status [GET|POST]
[GET| returns:
<states> <state> <level>info|warning|error</level>
id-string .... ... true|false </state> <state> .... </state> </states>So each plugin can return more than one message. The "level" will be displayed in the status module. "*_description" is a English default description which will be displayed if there is no translation on the WebYaST client side available. "message_id" indicates the translated message in the WebYaST client status module. If the user press the "confirm_button" a POST request will be send to the concerning service plugin. Then it is up to the service plugin to reset the state.
Not more would be needed from a plugin which intents to display a message/error in the status module.
The service status module "collects" all these messages and send it to the client status module which has to display the messages.
That would be one solution for displaying plugin messages. But perhaps there is another smarter one too. Suggestions :-)
Greetings Stefan
Webclient side: The status module checks each installed plugin if it has an interface
"status" and status_reset"
"status"
Hi, I see there two potential solution better then yours. Disadvantage of your solution is that you require interface, but this interface could be hidden in multi-resource resource like permission when status can be considered as user and it introduce unnecessary dependencies. So my solutions: Both solution use notifications. How this works? Simple you use in rest-service your status module and use static method notify problem. You can notify that problem appear or disappear. Implementation of notification is up to you (you can use db which we have on ws or files etc..). and then solution comes in different way how to handle when you know that problem exist. 1) simple know what each problem is and handle it in status module, easy to implement solution not so easy to extend, especially by external vendors 2) each ui controller which can have problems in ws has methods problems which return array of rendered contents for status notification. So it can include also link to fix it and other usability improvements - to be universal, you need to store name of controller, so you know which controller you must ask. (or you can simple ask all ui controller and don't need any notifications) Josef -- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, parts of webyast -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Monday 22 March 2010 13:26:12 Josef Reidinger wrote:
Implementation of notification is up to you (you can use db which we have on ws or files etc..). and then solution comes in different way how to handle when you know that problem exist.
This moves module specific know how into the status module. It needs to be maintained twice then.
1) simple know what each problem is and handle it in status module, easy to implement solution not so easy to extend, especially by external vendors
This isn't even easy to implement, as the status module needs to know how to query for exactly what in a foreign module - and if these modules change, the status module needs to be adapted too. This will sooner or later get inconsistent and messy.
2) each ui controller which can have problems in ws has methods problems which return array of rendered contents for status notification. So it can include also link to fix it and other usability improvements -
Why should this go into the ui controllers? Its the backend that knows about the status of the module or its configuration.
to be universal, you need to store name of controller, so you know which controller you must ask. (or you can simple ask all ui controller and don't need any notifications)
This "get the correct status" approach should become so generic that we should
not need to touch it anymore just to hook in any other module. Just think of
custom modules from software vendors. If they need to change our code to hook
in their modules it could damage even more.
But if we provide a generic framework everybody could easily include his
custom module to the status information.
The question now is, what is the best way to do it?
I like the idea that every module that responds to the method "status" could
will be integrated into the status info (see "status" as a symbol, we can of
course change that name). Thats a pretty simple way to offer thirt parties a
way to include their module status and a clean an generic way for ourselves.
And it even follows the basic concept of REST.
Ciao,
Daniel
--
J. Daniel Schmidt
On Monday 22 March 2010 13:26:12 Josef Reidinger wrote:
Both solution use notifications. How this works? Simple you use in rest-service your status module and use static method notify problem. You can notify that problem appear or disappear.
I just discussed the issue with Stefan and we found another problem with this
approach:
The notification approach might sound nice, but it reverses the way that
information flows for the status information. Stefan designed it the way, that
all status information is queried for. The notification approach relies on the
fact that the module puts its status information somewhere. That means, that
the module must have run bevore. But we can not guarantee that.
Easy example: a module that needs to be was not or was skipped (like
registration maybe). There is no chance for the module to put some information
if it did not run.
So the status information needs to be queried for - only this assures that the
module itself at least ran once and the module itself gathered all information
relevant for the status information. And it assures that the information is
uptodate.
A status information might even change without any change on the system itself
- the registration is a good example: When we in the future fix the
registration protocol and can get more information from NCC then the
registration state can change with a change on the registration server -
without any change on the appliance.
Ciao,
Daniel
--
J. Daniel Schmidt
participants (4)
-
J. Daniel Schmidt -
Jiří Suchomel -
Josef Reidinger -
Stefan Schubert