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.

Bug 42192 - Make Instantiating iterator
Summary: Make Instantiating iterator
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Dialogs&Wizards (show other bugs)
Version: 4.x
Hardware: All All
: P1 blocker (vote)
Assignee: Jiri Rechtacek
URL:
Keywords: API_REVIEW_FAST
: 34043 (view as bug list)
Depends on:
Blocks: 40894
  Show dependency tree
 
Reported: 2004-04-20 15:31 UTC by Jiri Rechtacek
Modified: 2008-12-22 21:49 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments
proposed InstantiatingIterator (1.40 KB, patch)
2004-04-20 15:35 UTC, Jiri Rechtacek
Details | Diff
next draft of task implementation (19.55 KB, patch)
2004-05-02 22:06 UTC, Jiri Rechtacek
Details | Diff
a draft of changes to avoid TW.I prepared to integrate (54.84 KB, patch)
2004-05-03 16:56 UTC, Jiri Rechtacek
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Rechtacek 2004-04-20 15:31:25 UTC
Buildsys asked make a Instantiating iterator (as
replacement of TemplateWizard.Iterator) This
iterator should be used in Projectui API.
Comment 1 Jiri Rechtacek 2004-04-20 15:35:45 UTC
Created attachment 14482 [details]
proposed InstantiatingIterator
Comment 2 Jesse Glick 2004-04-21 19:48:16 UTC
What is the 'Object settings' param to instantiate(...)? Can it be
removed?
Comment 3 Jiri Rechtacek 2004-04-22 08:48:58 UTC
By reason of Jarda's objection I assign back to me. The API change
should be implemented in WizardDescriptor (the methods be called in
right times), at least e.g. projectui/NewFileWizard uses it in
practice to figure out what methods and its parameters are useful, of
course code should be covered by a test.
Comment 4 Jaroslav Tulach 2004-04-23 17:13:27 UTC
Usecases needed. Please do not integrate an API without it being used
(at least in the test).

The way how I think the new interator should be used and tested:
TemplateWizard should allow this new interface to be assigned to
templates in layer. It is enough to rewrite TemplateWizard.getIterator
to do instanceof and in the case
WizardDescriptor.InstantiatingIterator is found wrap it by delegating
TemplateWizard.Iterator and use it. The test should create a
DataObject, mark it as template, write a serializable
InstantiatingIterator, assign it as a attribute to the DataObject's
primary file. Create TemplateWizard, set the object as template, try
to switch to next panel, check that the initialize method has been
called, ...., press finish and check that the instantiate method has
been called.

Second use case should be in plain WizardDescriptor. If a finish
button is pressed and the wizard is closed, it should check whether
the iterator implements InstantiableIterator and if so call its
instantiate method. It would be good if WizardDescriptor could then
return the set created objects. Maybe WD.getValue(), maybe new method?
The test would just create new WD with InstantiableIterator, check
that the initialize method has been called and then go thru panels
until finish is clicked. Then its instantiate method should be called
(this would be nice to check together with validation, if validation
fails the instantiate should not be called at all) and that the
correct value is not available from the WD.getValue (or the new method).


These two use cases should guarantee:
1. that we are not creating API that is not used at all
2. that we can use the API in templates
3. that we use the API in the same place where we define it
(openide/dialogs) and not just in openide/loaders

Btw. I agree with Jesse that the object argument to the instantiate is
ugly and seems useless.
Comment 5 Jesse Glick 2004-04-23 18:40:36 UTC
Sorry but we need this API very quickly. I don't care about automatic
usage from WizardDescriptor; we have no use case for that, it is
speculation. Usage from TemplateWizard is also irrelevant to us, and
serialized object compatibility is probably P3. We simply need a
non-loaders-specific replacement for TW.I, to be used immediately from
projects/projectuiapi and probably elsewhere (java/platform?). There
is no need for any test here because there should be no impl here,
only an interface. If you have other proposed uses for this interface,
great, but they should be filed and tracked separately and they are
probably not P1.
Comment 6 Jesse Glick 2004-05-01 02:19:25 UTC
*** Issue 34043 has been marked as a duplicate of this issue. ***
Comment 7 Jiri Rechtacek 2004-05-02 22:06:19 UTC
Created attachment 14661 [details]
next draft of task implementation
Comment 8 Jiri Rechtacek 2004-05-02 22:33:30 UTC
a attachment impl42192_draf2 contains:

1) implementation of WizardDescriptor.InstantiatingIterator in class
WizardDescriptor, the new methods are called in designed times
2) WizardDescriptor.InstantiatingIterator is used in TemplateWizard
3) WizardDescriptor.InstantiatingIterator replaces TemplateWizard in
projects/projectui and java/project on each place where can be
replaced w/o any change of implementaion
4) InstantiatingIterator is covered by InstantiatingIteratorTest

Note: this version isn't fully operarated (at least TemplateWizard's
part is buggy, but can be tested w/o it). Next versions will be continued.
Comment 9 Jiri Rechtacek 2004-05-03 16:56:31 UTC
Created attachment 14670 [details]
a draft of changes to avoid TW.I prepared to integrate
Comment 10 Jiri Rechtacek 2004-05-03 17:07:42 UTC
This impl42192_draft3.diff covered the changes and remarks raised
during API_REVIEW. I'm going to integrate it tomorrow (2004/05/04).
Thanks for opinions and advices.

The attached diff contains:
1) adds new InstantiatingIterator and implements it in WD
2) unit test covers InstantiatingIterator functionality
3) implements bridge to new iterator in TemplateWizard
4) WD.InstantiatingIterator replaces links to TemplateWizard in
projects/projectui and java/project on each place where can be
replaced w/o any change of implementation
5) beans and form modules declared project's JavaTemplates in its layers
Comment 11 Jiri Rechtacek 2004-05-04 13:11:50 UTC
The proposed draft #3 has been integrated in main trunk.