This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Wizard steps information should be bound to iterator (not to the panel) | ||
---|---|---|---|
Product: | platform | Reporter: | Jim Dibble <jdibble> |
Component: | Dialogs&Wizards | Assignee: | Jiri Rechtacek <jrechtacek> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | dsimonek, eadams, jrojcek, ttran |
Priority: | P3 | ||
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Windows 3.1/NT | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 26552 | ||
Bug Blocks: |
Description
Jim Dibble
2001-10-16 22:50:46 UTC
Trung, who will take this issue, when UI team do not do bugfixing at this time? David, please take care of this one 1. It is not a good idea to modify properties os someone else's panel. I strongly object to the mere idea of changing targetChooser's properties. If you feel that those should be customized it should not be that hard to create own panel (and/or iterator) and do whatever you find appropriate. 2. Check http://ui.netbeans.org/docs/ui_apis/wide/index.html Although it does not mention it explicitly there still are methods getClientProperty, so there is a way how to get hold of those values 3. I do agree that the steps information could be bound to the iterator rather that to the panel. As this is potential API enhancement I am changing the status of this report. Please note that you propose an incompatible API change - so I am also changing target milestone to 4.0. Also I am not sure that the change is really needed - that whould have to be discussed on openide-dev. The last paragraph of Jim's description looks like a very good suggestion. Ideally, a panel in wizard should not know where it sits in the bigger process. This separation would provide for easier reuse of wizard panels -- a good thing. I'm not familar with the Wizard APIs. Would this have to be an incompatible API change, or could it be done by adding new APIs? For example, we could provide APIs to set the properties on the TemplateWizardIterator. In order to ensure backward compatibility, then the TemplateWizardIterator would let the panel's properties override. Just a thought. If the changes are indeed incompatible, then what is the recommended short-term solution? I agree that its bad form to modify the properties of someone else's panel. Is the recommended short-term solution something like this: - if you are using a wizard template, unmodified, then nothing new needs to be done - if you need to modify the properties of some panels then there might be several options (remember I'm not familar with the APIs :-) . create your own TemplateWizardIterator and clone the the panels from the orignal template . remember to unset the properties when the wizard is finished. This assumes there is just one wizard available at a time. Is this assumption correct? This might be done by adding a method to the TemplateWizardIterator that will clear/reset the clear/reset the wizard-specific properties of the panels. . others? By associating the data with the TemplateWizardIterator then there would be no need to clone the panels. Passing to new owner No changes planned to 3.6. Not planed for ever |