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 current Wizard API forces client code to use JComponent.putClientProperty() to communicate its requests to the wizard infrastructure. This is weird. We should use regular java setters/getters instead. putClientProperty() must still work for backward compat reasons.
Note: method WizardDescriptor.Panel.isValid() should be renamed; there is a clash with JPanel.isValid().
Requirement (issue 30208): Specify order calling the API methods: i.e. readSettings assumes created component because multiple invoke readSettings have to have the same effect, it doesn't differ if component is created or isn't created, readSettings precedes writeSettings etc. Requirement: replace WD.getComponet with createComponent which can by called only once (name "getComponent" is confusing because is called several times and shouldn't create new component each time).
Copy & pasting from openide-dev discussion. The current state is IMHO reflects the history and evolution of the API quite well, but it's not very usable. I imagine we've had just NotifyDescriptors in at the beginning, for showing messages. then someone came up with the idea that a dialog is actually just a custom message and came up with DialogDescriptor, later taht was extended, because Wizards are just a sequence of dialogs, right? TemplateWizard is a natural last step so far. So all these form one nice inheritance tree, however the problem is that you can call safely only the wizarddescriptor's methods when dealing with wizard and should not try to call anything that smells like a method from NotifyDescriptor or dialogdescriptor, because these would break the whole thing. So why have them extend it after all?
It's a umbrella issue, not direct ask of projects team => removed 'projects' flag.
Replace relation depends on to blocks, i.e. the this umbrella issue will depend on enhancements and task against wizard and these issues won't depend on this issue.
Not planned for ever