Mailinglist Archive: yast-devel (59 mails)

< Previous Next >
Re: [yast-devel] Showing state of WebYaST plugins in status plugin.
  • From: Josef Reidinger <jreidinger@xxxxxxx>
  • Date: Mon, 22 Mar 2010 13:26:12 +0100
  • Message-id: <201003221326.13452.jreidinger@xxxxxxx>
Stefan Schubert write:
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
if he has received the email. This message disappears after he has
confirmed the receive
in the status module.

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

registration/registration/status [GET|POST]

[GET| returns:


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
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 :-)


Webclient side:
The status module checks each installed plugin if it has an interface

"status" and status_reset"


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 Reidinger
YaST team
maintainer of perl-Bootloader, YaST2-Repair, parts of webyast
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >