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.
The TemplateWizard's targetChooser() method reuses the panel for choosing a target. This can cause a problem if one wizard implementation attaches steps to the targetChooser panel, and another wizard implementation does not. For example, a wizard with steps would have the following code: JComponent c = (JComponent)(panelList[i].getComponent()); c.putClientProperty("WizardPanel_contentData", panelNames); c.putClientProperty("WizardPanel_contentSelectedIndex", new Integer(i)); Another module that uses the default template wizard (does not add any additional panels), can just specify the plain template wizard in the mf-layer file. It does not need to implement the TemplateWizardIterator, as the default implementation is used. If the user executes these wizards in the above order, the steps from the first wizard appear on the second wizard. The best solution to this problem would be to modify the TemplateWizardIterator interface to return the list of steps for the current panel. In this way, any panel can be reused in any number of wizards (or within the same wizard) without knowing its position in the larger process. (The panel name and step names should not be attached to the panel, because it should not know how it is being used in the larger process.)
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