Forum OpenACS Development: New Wizard in development
I have made some changes in the wizard-procs. Here are changes made:
- wizard step can now have wizard steps. That means wizard within a wizard. Any level deep.
- wizard params are now tracked by ad_client_property not by passing http vars. We can still do it by http vars but it is just not easy to do. I have removed the http vars from being passed.
- added template::wizard::get_param call.
Difference in behaviour to current wizard:
- finish button now does not go back to step 1. but goes one level higher. We have subwizard, so its natural to go back to the parent wizard. Rather than the subwizard going over and over again.
- "-action" on sub wizards does not affect anything.
- ad_page_contract is not used anymore to get the params, rather use wizard::get_param tcl call.
- more testing.
- change all proc to ad_proc.... not sure. But if I have time I will rewrite all procs.
- scope the wizard name down to package level and not system level. Maybe. Not sure. Since this is just affects the param. Maybe I will just scope the params by package_id and wizard name, not just wizard name.
- put into contrib CVS for review. (I will do this in 2-3 weeks after the project)
minus the finish button difference. Only subwizard moves up, while the main wizard still goes to step1, just like the current wizard.
munus the package level scoping of the vars in the todo. I have done it.
This sounds very neat! Watch out or you'll be called the "Wizard of OS"
Do you have a demo of this somewhere?
I have a question about the ad_page_contract comment. Is that internal to the wizard or are you talking about client package code? ad_page_contract is far, far preferable to the ATS param code.
No demo site. I can however provide you a tar ball of test files using the new wizard and wizard-procs.tcl of acs-templating/tcl. You can also wait for a copy on contrib in 2-3 weeks time. Its based from ACS 4.1.1, I haven't diffed it yet from current wizard-procs.tcl. But I am sure that there is very little difference, not much people used wizards.
Yes its the client code that needs to change. Previously for you to get a wizard param that you set by wizard::set_param, to get it use ad_page_contract. For example step 1 set myparam. On step 2 to get myparam you put myparam on ad_page_contract. Now what you do is on step 2 is "set myparam [template::wizard::get_param myparam]". I thought in the short time I need to implement the project, i can't beboptized the wizard. So hehehe cheat on ad_client_property :). Params are scoped by package_id, wizard_name and param_name. If implementation is to change in the future we can just change the get_param and set_param calls. And the wizard will still be happy :) Better abstraction.
It seems using ad_client_property to keep the wizard params was not a good design. We have problems integrating it with none wizard pages that wish to directly use the sub wizards. For example if we have a sub wizard that we wish to reuse from other pages. We can't set the params of the sub wizard from a normal tcl page, since the wizard has not been created yet, hence no wizard::set_param yet. I will revert back using http vars so pages can link and populate the http vars.
Collision of the params will also be given back to the developer to make sure that it does not collide.
I have committed the modified wizard on /contrib/misc of HEAD.
I hope that it will be useful. Also it can replace the existing wizard-procs.tcl will little modification to existing code. Who is the maintener of acs-templating?
Please kindly give it a whirl and test. I just modified some procs to remove some client specific stuff.
Next stop continuation of bcms. :)
This is too important to be left solely in contrib.
The changes should be minimal or maybe even none. Since I tried to make it as compatible as possible.
I believe only CMS uses the wizard in the official tree. And for some dumb luck I have used wizard already for 2 projects. Its really funny how much mileage we got out of the wizard in the last project. The UI does not even look like a wizard. :)
I will test if CMS still works with the modified one. I will make a diff patch if needed. After testing can I just ask you, Jeff or Lars to plug in the wizard-procs.tcl and wizard-procs-doc.html to acs-templating?
Here is the only thing I can see to make the existing code that uses the wizard run. Actually it should have been 100% compatible if it wasn't for the unconventional way of the use of wizard in cms. It was using the wizard action url as its finish url. Anyway the modified wizard luckily did have a way for you to set the finish url since we have found this useful in our project.
--- home/nsadmin/servers/openacs-4/packages/cms/www/modules/types/widget-register.tcl 2003-07-02 20:32:18.000000000 +0800
+++ widget-register.tcl 2003-07-12 18:20:48.000000000 +0800
@@ -25,5 +25,6 @@
2 -label "Edit Widget Params" -url "widget-register-2"
3 -label "Preview Widget" -url "widget-register-3"
+wizard set_finish_url "index?id=$content_type"
Apply the patch. Drop in the wizard-procs.tcl and put the wizard-procs-doc.html in a sane place and add a link.
The current modified wizard is still far from perfect. As I could not 100% port to ad_proc. I did use ad_proc on all procs. But template::util::get_opts $args can be eliminated and have the $args parsed in ad_proc. Also it still uses template::forward, not sure if ad_returnredirect is better. Its in better shape than before, with 90+% compatibility, added features, better documentation.
On a off topic. Does the current CMS 4.6.3 run on pg7.3.x? It seems I have to change some type cast when clicking on the site map and template folder. Also I can't seem to create new content as the revision_id is not being properly set. I am not yet submitting a bug, since it might be just a case that my db has some problem or something.