[yast-devel] Webyast base system model proposal
Hi, base system model is something like first boot which ensure basic settings after first login to rest-service of target machine. First I describe how it should look from user perspective. User login to target machine and then he see first module from first boot sequency, after saving settings go to next step until last one is complete and then show standard control panel. Implementation proposal: Create new rest-service for first boot. This module store in database last successfully saved module. It also contains list of modules and its order. So frontend ask only what module is next one. If next one is control panel, then first boot is complete passed. Frontend is implemented mostly in control panel. It ask backend for next module in first boot order. If next module is not control panel, then control panel redirect to that module. The most complicated think is how recognize, that module settings is successfully set. My proposal is set to session in control panel, that modul must set status. If user successfully set settings that corresponding module set status to OK and control panel send this information to rest module and look what is next module to pass. pros: * Minimal changes to current code * Easily manageable order and modules in first boot neg: * Each modules must handle request to status * somehow must be solved returning from module to control panel (redirect after success save?), as browser back doesn't work as expected thanks for opinions and suggestions, Josef -- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast modules language and time -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
[I guess I replied to this mail in FATE only] * Josef Reidinger <jreidinger@suse.cz> [Aug 13. 2009 14:05]:
Hi, base system model is something like first boot which ensure basic settings after first login to rest-service of target machine. First I describe how it should look from user perspective. User login to target machine and then he see first module from first boot sequency, after saving settings go to next step until last one is complete and then show standard control panel.
Yes, thats how I also understand the feature request. Ideally, the modules to call and their ordering is freely configurable so vendors can add and remove modules as needed.
Implementation proposal: Create new rest-service for first boot. This module store in database last successfully saved module. It also contains list of modules and its order. So frontend ask only what module is next one. If next one is control panel, then first boot is complete passed.
I do not think that this requires a REST service. Calling configuration modules in a specific order is pure client side (web ui) functionality imho.
Frontend is implemented mostly in control panel. It ask backend for next module in first boot order. If next module is not control panel, then control panel redirect to that module.
Keeping it all in the frontend should be sufficient. Are there any specific requirements for using the backend here ?
The most complicated think is how recognize, that module settings is successfully set. My proposal is set to session in control panel, that modul must set status.
A 'configuration needed' status belongs to the (REST)service, not to the session. The backend service is the authorative source of this state information. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 08/17/2009 01:02 PM, Klaus Kaempf wrote:
[I guess I replied to this mail in FATE only]
* Josef Reidinger <jreidinger@suse.cz> [Aug 13. 2009 14:05]:
Hi, base system model is something like first boot which ensure basic settings after first login to rest-service of target machine. First I describe how it should look from user perspective. User login to target machine and then he see first module from first boot sequency, after saving settings go to next step until last one is complete and then show standard control panel.
Yes, thats how I also understand the feature request.
Ideally, the modules to call and their ordering is freely configurable so vendors can add and remove modules as needed. It is simple list in text file. (see backend basicsystem/config/basesystemsteps.conf)
Implementation proposal: Create new rest-service for first boot. This module store in database last successfully saved module. It also contains list of modules and its order. So frontend ask only what module is next one. If next one is control panel, then first boot is complete passed.
I do not think that this requires a REST service. Calling configuration modules in a specific order is pure client side (web ui) functionality imho.
I think client side is not sufficient as you must somewhere store what is already configured and what missing. What should be changed is place where is
Frontend is implemented mostly in control panel. It ask backend for next module in first boot order. If next module is not control panel, then control panel redirect to that module.
Keeping it all in the frontend should be sufficient. Are there any specific requirements for using the backend here ?
Backend know what is done and what missing. E.g if you have two machine with front-end and you already configure basic system settings on one for target machine M. Then you don't want again configure it on second machine.
The most complicated think is how recognize, that module settings is successfully set. My proposal is set to session in control panel, that modul must set status.
A 'configuration needed' status belongs to the (REST)service, not to the session. The backend service is the authorative source of this state information.
I plan use "configuration needed" for wizard purpose, so when configuration needed is set then via layout (I plan discuss it with our external consultant) show next/back(?) buttons and after clicking on next is stored that this part of configuration is done. So this state say only that we want show navigation thrue basic settings. This navigation then ensure information for backend that user configure it. We use it because system is already set to some default and some users just want confirm settings ( also it helps in complicated modules). It is same as in first boot when some pages is shown and after next is shown next page. What should be confusing is that next button doesn't save settings. User must save it before continue to next page. -- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast modules language and time -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Aug 17. 2009 13:19]:
I do not think that this requires a REST service. Calling configuration modules in a specific order is pure client side (web ui) functionality imho.
I think client side is not sufficient as you must somewhere store what is already configured and what missing.
The respective backend service should be able to report its status. I fail to see the need for keeping this information in a separate database (resp. service). Maybe I'm overlooking the obvious, though ... [...]
I plan use "configuration needed" for wizard purpose, so when configuration needed is set then via layout (I plan discuss it with our external consultant) show next/back(?) buttons and after clicking on next is stored that this part of configuration is done.
This looks more like a generic 'workflow' or 'wizard'. Thats something for our UI guys ;-) (Robert L., Martin S.). Pleass have them involved.
So this state say only that we want show navigation thrue basic settings.
Ah, so you're storing the 'step' (index into basesystemsteps.conf) in the session ?!
This navigation then ensure information for backend that user configure it. We use it because system is already set to some default and some users just want confirm settings ( also it helps in complicated modules).
Agreed.
It is same as in first boot when some pages is shown and after next is shown next page.
I don't quite understand this.
What should be confusing is that next button doesn't save settings. User must save it before continue to next page.
Agreed. "Next" should always be identical to "Ok" (in 'edit' dialogs) and save changes. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 08/17/2009 02:25 PM, Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [Aug 17. 2009 13:19]:
I do not think that this requires a REST service. Calling configuration modules in a specific order is pure client side (web ui) functionality imho.
I think client side is not sufficient as you must somewhere store what is already configured and what missing.
The respective backend service should be able to report its status. I fail to see the need for keeping this information in a separate database (resp. service).
Maybe I'm overlooking the obvious, though ...
Yes it should be possible, but then all modules must provide unified way how to report, that it is not configured and it is often not stored anywhere. Like for timezone from installation some default timezone is choose. So rest-service must store that timezone is not ever saved. Second problem which I see is how to get last done step...It should end with list of modules which must be check after each login, which should cause performance problem.
[...]
I plan use "configuration needed" for wizard purpose, so when configuration needed is set then via layout (I plan discuss it with our external consultant) show next/back(?) buttons and after clicking on next is stored that this part of configuration is done.
This looks more like a generic 'workflow' or 'wizard'. Thats something for our UI guys ;-) (Robert L., Martin S.). Pleass have them involved.
OK, tomorrow I try get all possible solution and write them.
So this state say only that we want show navigation thrue basic settings.
Ah, so you're storing the 'step' (index into basesystemsteps.conf) in the session ?!
No, it is stored in separated file in base system backend.
This navigation then ensure information for backend that user configure it. We use it because system is already set to some default and some users just want confirm settings ( also it helps in complicated modules).
Agreed.
It is same as in first boot when some pages is shown and after next is shown next page.
I don't quite understand this.
I just want to say, that it act same as during first boot when user can just confirm settings on page and after clicking on next he see next settings which he can change or also just confirm.
What should be confusing is that next button doesn't save settings. User must save it before continue to next page.
Agreed. "Next" should always be identical to "Ok" (in 'edit' dialogs) and save changes.
I discuss possible solution tomorrow with rails consultant (we must submit form and also redirect in one step).
Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
-- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast modules language and time -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Aug 17. 2009 14:35]:
On 08/17/2009 02:25 PM, Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [Aug 17. 2009 13:19]:
I do not think that this requires a REST service. Calling configuration modules in a specific order is pure client side (web ui) functionality imho.
I think client side is not sufficient as you must somewhere store what is already configured and what missing.
The respective backend service should be able to report its status. I fail to see the need for keeping this information in a separate database (resp. service).
Maybe I'm overlooking the obvious, though ...
Yes it should be possible, but then all modules must provide unified way how to report, that it is not configured and it is often not stored anywhere.
Right. This needs to be added to all (affected) services.
Like for timezone from installation some default timezone is choose. So rest-service must store that timezone is not ever saved.
Not necessarily. If a service has a default configuration, there no need to reconfigure it. All the workflow module needs is a 'last successfully visited module' in the session. From this, it can navigate to the next dialog. If the session is closed, the setup workflow will be restarted. For the already configured modules, the user just clicks on 'next'.
Second problem which I see is how to get last done step...It should end with list of modules which must be check after each login, which should cause performance problem.
All you need is a "setup workflow finished" flag on the client side. This is basically a "touch" operation to a specific file after the last config step. Ah simple "File.exists?(...)" after each login shouldn't be a performance problem.
I discuss possible solution tomorrow with rails consultant (we must submit form and also redirect in one step).
Please capture the discussion and share them with the team. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
After thinking about it, I believe the 'base system model' can be vastly simplified. * Klaus Kaempf <kkaempf@suse.de> [Aug 17. 2009 15:04]:
* Josef Reidinger <jreidinger@suse.cz> [Aug 17. 2009 14:35]:
Yes it should be possible, but then all modules must provide unified way how to report, that it is not configured and it is often not stored anywhere.
Right. This needs to be added to all (affected) services.
Actually, there's no need to change or implement any service. You only need two state informations 1. The last (or currently) visited step of the workflow This belongs to the session information (cookie) of the browser. If this information is present, the workflow engine knows what to call next. If this information is not present, the workflow engine either restarts from beginning or does not start at all. To decide this, one needs: 2. If the setup workflow was finished successfully This belongs to the backend as non-privileged information. It can be as simple as touching a file (e.g. below /etc/webyast). As long as the file does not exist, the user is forced into the basic setup workflow after login. If the file exists, the user is redirected to the controlpanel after login. This decision can be easily implemented in the webclients MainController. The file approach also has the advantage that the backed can easily resetted to re-run the setup workflow by removing the file. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 08/18/2009 10:23 AM, Klaus Kaempf wrote:
After thinking about it, I believe the 'base system model' can be vastly simplified.
* Klaus Kaempf <kkaempf@suse.de> [Aug 17. 2009 15:04]:
* Josef Reidinger <jreidinger@suse.cz> [Aug 17. 2009 14:35]:
Yes it should be possible, but then all modules must provide unified way how to report, that it is not configured and it is often not stored anywhere.
Right. This needs to be added to all (affected) services.
Actually, there's no need to change or implement any service.
You only need two state informations
1. The last (or currently) visited step of the workflow
This belongs to the session information (cookie) of the browser. If this information is present, the workflow engine knows what to call next. If this information is not present, the workflow engine either restarts from beginning or does not start at all. To decide this, one needs:
2. If the setup workflow was finished successfully
This belongs to the backend as non-privileged information. It can be as simple as touching a file (e.g. below /etc/webyast). As long as the file does not exist, the user is forced into the basic setup workflow after login. If the file exists, the user is redirected to the controlpanel after login. This decision can be easily implemented in the webclients MainController.
The file approach also has the advantage that the backed can easily resetted to re-run the setup workflow by removing the file.
Yes, it is similar how I implemented it now except, that it remember done steps in backend and not session, so if you configure two modules and another three remain, then you can just after new login configure remaining three. I hope I have to the end of week working prototype. And then we could discuss about improvements. (I think that practical example shows more problems then theoretical discussion). -- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast modules language and time -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Aug 18. 2009 12:35]:
Yes, it is similar how I implemented it now except, that it remember done steps in backend and not session, so if you configure two modules and another three remain, then you can just after new login configure remaining three.
I fail to see the need for this. Storing such status in the backend either needs an extension to every service or a separate 'workflow status' service.
I hope I have to the end of week working prototype. And then we could discuss about improvements. (I think that practical example shows more problems then theoretical discussion).
Agreed. But even spending half a day on a prototype shouldn't be done without planning and discussing the concept. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 08/18/2009 01:55 PM, Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [Aug 18. 2009 12:35]:
Yes, it is similar how I implemented it now except, that it remember done steps in backend and not session, so if you configure two modules and another three remain, then you can just after new login configure remaining three.
I fail to see the need for this. Storing such status in the backend either needs an extension to every service or a separate 'workflow status' service.
Yes, separate workflow service, but I find it useful, because if you set only part of settings and want continue another day, it is possible. And it also support business case for companies where each employer configure another part and have another permissions. If we store completed settings in session it is not possible to have rest-service where one technician should set time, timezone and second one root password and error mail.
I hope I have to the end of week working prototype. And then we could discuss about improvements. (I think that practical example shows more problems then theoretical discussion).
Agreed. But even spending half a day on a prototype shouldn't be done without planning and discussing the concept.
Ruby and also Rails is great that you can prototype really fast, try find problems and change your code quite fast. This is different from languages like C or java where each change is a lot of work and also more errorneous. So you can try how looks your ideas quick and try how it is useful. -- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast modules language and time -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Aug 18. 2009 14:50]:
On 08/18/2009 01:55 PM, Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [Aug 18. 2009 12:35]:
Yes, it is similar how I implemented it now except, that it remember done steps in backend and not session, so if you configure two modules and another three remain, then you can just after new login configure remaining three.
I fail to see the need for this. Storing such status in the backend either needs an extension to every service or a separate 'workflow status' service.
Yes, separate workflow service, but I find it useful, because if you set only part of settings and want continue another day, it is possible.
Thats too little value for too much work, I'm afraid.
And it also support business case for companies where each employer configure another part and have another permissions. If we store completed settings in session it is not possible to have rest-service where one technician should set time, timezone and second one root password and error mail.
So called 'separation of duty' is required in big enterprise scenarios and WebYaST covers this with PolicyKit. I strongly suggest to leave it that way. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
In *basesystem branch* I create proposal implementation. Everyone could try it. What is missing from target implementation: configuration is not read from YaML and target location but from plugins/basesystem//config/basesystemsteps.conf and it is one line per controller next doesn't save changes settings (Klaus do we want it?) communication is planned to changed, as some artifact remain from previous implementation (and maybe we should better use ActiveResource abilities) no tests now (I know it is not test-driven development) I welcome any comments how to improve it. -- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast modules language and time -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Aug 20. 2009 14:39]:
In *basesystem branch* I create proposal implementation. Everyone could try it.
Thanks !
What is missing from target implementation: configuration is not read from YaML and target location but from plugins/basesystem//config/basesystemsteps.conf and it is one line per controller
Ok. Does Duncans 'settings' controller fit your needs ?
next doesn't save changes settings (Klaus do we want it?)
Yes, I think so. The 'basic setup' should just call other modules in the right order. When one module is done, it should save the changes.
communication is planned to changed, as some artifact remain from previous implementation (and maybe we should better use ActiveResource abilities)
Can you share more details please ?
no tests now (I know it is not test-driven development)
This should be the first thing to fix on monday morning ;-) Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 08/24/2009 09:43 AM, Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [Aug 20. 2009 14:39]:
In *basesystem branch* I create proposal implementation. Everyone could try it.
Thanks !
What is missing from target implementation: configuration is not read from YaML and target location but from plugins/basesystem//config/basesystemsteps.conf and it is one line per controller
Ok. Does Duncans 'settings' controller fit your needs ?
Yes, it was in plan and now I implemented it.
next doesn't save changes settings (Klaus do we want it?)
Yes, I think so. The 'basic setup' should just call other modules in the right order. When one module is done, it should save the changes.
OK, then we must find some way how to ensure it. I think the best solution is that each module must have something like general safe form button which is called by javascript on "next" button and maybe same after filter in application controller that in wizard mode redirect after submitting this form to control panel.
communication is planned to changed, as some artifact remain from previous implementation (and maybe we should better use ActiveResource abilities)
Can you share more details please ?
OK, after discussion with mkudlvasr it now contains two fields. First one is step definition which is array of strings. Strings is path to redirect. second field is boolean which indicate if first boot is already done. e.g. <basesystem> <finish type="boolean">false</finish> <steps type="array"> <step>systemtime</step> <step>language</step> </steps> </basesystem>
no tests now (I know it is not test-driven development)
This should be the first thing to fix on monday morning ;-)
Backend already have tests (thanks to mkudlvasr). Frontend doesn't have it, I hope it should have ASAP. martin - could you do it?
Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
-- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast modules language and time -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Aug 24. 2009 16:03]:
Yes, I think so. The 'basic setup' should just call other modules in the right order. When one module is done, it should save the changes.
OK, then we must find some way how to ensure it. I think the best solution is that each module must have something like general safe form button which is called by javascript on "next" button and maybe same after filter in application controller that in wizard mode redirect after submitting this form to control panel.
I still haven't fully understood what you're trying to accomplish here.
communication is planned to changed, as some artifact remain from previous implementation (and maybe we should better use ActiveResource abilities)
Can you share more details please ?
OK, after discussion with mkudlvasr it now contains two fields. First one is step definition which is array of strings. Strings is path to redirect.
You're making assumption about how an URL is contructed, this will break with future updates. Better specify by controller/action.
second field is boolean which indicate if first boot is already done.
I think this was discussed in a thread last week already and is not needed iirc. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 08/24/2009 04:38 PM, Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [Aug 24. 2009 16:03]:
Yes, I think so. The 'basic setup' should just call other modules in the right order. When one module is done, it should save the changes.
OK, then we must find some way how to ensure it. I think the best solution is that each module must have something like general safe form button which is called by javascript on "next" button and maybe same after filter in application controller that in wizard mode redirect after submitting this form to control panel.
I still haven't fully understood what you're trying to accomplish here.
I only want that after click on next changes in form is saved even if you don't press Save. (you can try it now in base system branch, where it doesn't save settings from form after press on next)
communication is planned to changed, as some artifact remain from previous implementation (and maybe we should better use ActiveResource abilities)
Can you share more details please ?
OK, after discussion with mkudlvasr it now contains two fields. First one is step definition which is array of strings. Strings is path to redirect.
You're making assumption about how an URL is contructed, this will break with future updates. Better specify by controller/action.
OK...and without action is it OK to fallback to index action?
second field is boolean which indicate if first boot is already done.
I think this was discussed in a thread last week already and is not needed iirc.
I do as we I understand from your mail: quote: "This belongs to the backend as non-privileged information. It can be as simple as touching a file (e.g. below /etc/webyast). As long as the file does not exist, the user is forced into the basic setup workflow after login. If the file exists, the user is redirected to the controlpanel after login. " It is simple checking of file existency, but this information must be on rest-service side, so in xml is result of File.exist?...I think it is efficient. It ask only once after login to steps and finish. If finished then ignore steps and if not yet finished follow steps. I must somehow get information from backend that for target system finish its base setup.
Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
-- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast modules language and time -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Aug 24. 2009 16:46]:
I only want that after click on next changes in form is saved even if you don't press Save. (you can try it now in base system branch, where it doesn't save settings from form after press on next)
Wouldn't it be easier to call a module 'as is', just with a special parameter ('wizard') to change the Ok/Cancel buttons into Next/Back ?
You're making assumption about how an URL is contructed, this will break with future updates. Better specify by controller/action.
OK...and without action is it OK to fallback to index action?
Prepare for specifying the action but leave out for the current modules.
second field is boolean which indicate if first boot is already done.
I think this was discussed in a thread last week already and is not needed iirc.
I do as we I understand from your mail: quote: "This belongs to the backend as non-privileged information. It can be as simple as touching a file (e.g. below /etc/webyast). As long as the file does not exist, the user is forced into the basic setup workflow after login. If the file exists, the user is redirected to the controlpanel after login. "
It is simple checking of file existency, but this information must be on rest-service side, so in xml is result of File.exist?...I think it is efficient.
Ah, now I understand. I just didn't get the 'link' from your initial explanation. Sorry for the confusion. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 08/24/2009 05:14 PM, Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [Aug 24. 2009 16:46]:
I only want that after click on next changes in form is saved even if you don't press Save. (you can try it now in base system branch, where it doesn't save settings from form after press on next)
Wouldn't it be easier to call a module 'as is', just with a special parameter ('wizard') to change the Ok/Cancel buttons into Next/Back ?
Yes, it should be possible...I think that we should have some universal method for button names (I think lslezak create something similar) and in this method rename it.
You're making assumption about how an URL is contructed, this will break with future updates. Better specify by controller/action.
OK...and without action is it OK to fallback to index action?
Prepare for specifying the action but leave out for the current modules.
OK
second field is boolean which indicate if first boot is already done.
I think this was discussed in a thread last week already and is not needed iirc.
I do as we I understand from your mail: quote: "This belongs to the backend as non-privileged information. It can be as simple as touching a file (e.g. below /etc/webyast). As long as the file does not exist, the user is forced into the basic setup workflow after login. If the file exists, the user is redirected to the controlpanel after login. "
It is simple checking of file existency, but this information must be on rest-service side, so in xml is result of File.exist?...I think it is efficient.
Ah, now I understand. I just didn't get the 'link' from your initial explanation. Sorry for the confusion.
OK. So for me, missing only: - tests for frontend - change save and cancel buttons in modules to use more general function that can rename it and solve redirecting after handling form. - change sending string to controller and action if present. -- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast modules language and time -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Aug 24. 2009 17:20]:
On 08/24/2009 05:14 PM, Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [Aug 24. 2009 16:46]:
I only want that after click on next changes in form is saved even if you don't press Save. (you can try it now in base system branch, where it doesn't save settings from form after press on next)
Wouldn't it be easier to call a module 'as is', just with a special parameter ('wizard') to change the Ok/Cancel buttons into Next/Back ?
Yes, it should be possible...I think that we should have some universal method for button names (I think lslezak create something similar) and in this method rename it.
Thats what the UI guys (Martin and Robert) are responsible for. Just ask them ;-)
So for me, missing only: - tests for frontend - change save and cancel buttons in modules to use more general function that can rename it and solve redirecting after handling form. - change sending string to controller and action if present.
Sounds good to me :-) Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Monday 24 August 2009 17:14:41 Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [Aug 24. 2009 16:46]:
I only want that after click on next changes in form is saved even if you don't press Save. (you can try it now in base system branch, where it doesn't save settings from form after press on next)
Wouldn't it be easier to call a module 'as is', just with a special parameter ('wizard') to change the Ok/Cancel buttons into Next/Back ?
I think that we should keep it simple. With Josef's proposal, the module/plugin is still called "as is". No change to the modules is needed except marking the Ok/Save buttons with some globally unique id. When the user clicks Next, Save button will be clicked by ajax. It will find the submit button by the id and it can also wait for the result. After that the Next button will be clicked/submitted (still by ajax). I think that Ok/Cancel serves a different purpose than Next/Back. By mixing the behaviour of these 2, we would create a strong link between basesystem and all other modules, which would be hard(er) to maintain. We would need all other modules to: - Have both Ok/Save AND Cancel button - Placement of Ok/Cancel button will have to be the same in all modules (otherwise user will be confused while base system setup) - Use our special functions to generate the buttons. The Back/Next buttons will be rendered differently for first and last module from basesystem steps list (no button/Next for first, Back/Finish for last) From my POV, using ajax to click on the save buttons is a better solution. Martin Kudlvasr -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Martin Kudlvasr <mkudlvasr@suse.cz> [Aug 25. 2009 15:41]:
From my POV, using ajax to click on the save buttons is a better solution.
Ok, I'm fine with your decision. Now please contact rlihm for help with the UI (and don't spend time writing JavaScript ;-)) Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (3)
-
Josef Reidinger -
Klaus Kaempf -
Martin Kudlvasr