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> > <message_id>id-string</message_id> > <short_description>....</short_description> > <long_description>...</long_description> > <confirm_button>true|false</confirm_button> > </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: [email protected] For additional commands, e-mail: [email protected]
