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_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
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
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.
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