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 15267

Summary:	[2004-05-15] Insufficient API for TemplateWizard iterators
Product:	platform	Reporter:	Svata Dedic <sdedic>
Component:	Dialogs&Wizards	Assignee:	Jiri Rechtacek <jrechtacek>
Status:	RESOLVED DUPLICATE
Severity:	blocker	CC:	eakle, vstejskal
Priority:	P2	Keywords:	API, UI, UMBRELLA
Version:	3.x
Hardware:	All
OS:	All
Issue Type:	ENHANCEMENT	Exception Reporter:
Bug Depends on:	7706, 23116, 25561, 35787
Bug Blocks:	11694, 17937, 18842

Description Svata Dedic 2001-09-07 17:08:55 UTC

I lack some things in the API
1. plug in validators for object name, target folder name.
The current API only allows to inform the user when the target chooser panel 
is going away. It is a solution, but some actions which are already done are 
irreversible, like creation of nonexistent folders.
Next, the API does not allow the control of Next and Finish button - it is 
possible to invalidate the panel, but the standard target chooser does not 
provide a way to find out what folder and name are entered right now. It can 
only write them to the wizard.

2. Querying for selected target folder will create folders, if the name 
entered by the user does not exist.
This is terrible, because there can be other pannels and the user can cancel 
them, leaving debris on his harddrive.

3. Finish button should not be controlled statically, by implementing a 
interface. The choice has to be dynamic, based on the entered values. Right 
now, it is not possible to disable only Finish by evaluating user input - it 
has to be either enabled (provided the panel says its valid) or disabled for a 
given panel.

4. The wizard incorporates a logic, which hide the package chooser and 
replaces it with a simple name text field, if the user (somehow) made the 
desired folder known to the IDE. This logic is burried in the wizard 
(combination of state variable and method parameter, whose cannot be accessed 
outside the wizard). 
Custom target chooser implementations cannot reuse this logic or gather all 
necessary data to perform their own logic.

[1. and 4. implies that standard target chooser, while suitable for most of 
the object types cannot be easily reused by custom wizard iterators]

Comment 1 Jan Chalupa 2001-11-27 13:02:04 UTC

Target milestone -> 3.3.1.

Comment 2 David Simonek 2002-01-28 16:29:16 UTC

Reassigning to Marek, evaluate, please. Thsnks.

Comment 3 mslama 2002-01-29 09:50:17 UTC

It requires API change, to be discussed.

Comment 4 David Simonek 2002-02-06 16:23:02 UTC

sidenote - part #3 i required by UI team.

Comment 5 David Simonek 2002-02-08 12:07:22 UTC

*** Issue 20324 has been marked as a duplicate of this issue. ***

Comment 6 Vitezslav Stejskal 2002-04-08 19:35:01 UTC

CCing myself.

Comment 7 eakle 2002-05-01 19:46:25 UTC

There are also times when different processing needs to 
occur on Finish, that doesn't need to occur on Next or 
Back (and it needs to occur in the step panel, not in the 
wizard), so we also need a way to know which button the 
user has pressed (and we need to know this within the step 
panel's storeSettings() method).

Comment 8 pete eakle 2002-05-03 16:29:39 UTC

see also 23116 (wizard step needs ability to veto the 
Next / Finish buttons and keep user in current step)

Comment 9 Marek Grummich 2002-07-22 11:30:16 UTC

Set target milestone to TBD

Comment 10 Marek Grummich 2002-07-22 11:32:18 UTC

Set target milestone to TBD

Comment 11 _ ttran 2002-07-30 15:50:21 UTC

officially requested by S1S, planned for 4.0, upped prio to P1

Comment 12 Jiri Rechtacek 2002-09-06 09:43:44 UTC

add 2. create a folder when instantiate()
add 3. dynamic enable/disable finish button, will be soleved by issue 7706
add 4. will be soleved by issue 25561

Comment 13 Svata Dedic 2002-09-06 09:49:46 UTC

ad 1) if one calls getTargetFolder() during the Wizard - the new
folder gets created immediately.
I needed to call that function so I could prevent creating classes in
folders named "e-e" or "x.y" which are not valid package names.
There's no call currently to find the proposed folder name (for the
case the folder does not exist yet).

Comment 14 Jaroslav Tulach 2002-09-30 12:59:19 UTC

These issues have been reported to be part of Sun's "should have" contribution
to NetBeans 4.0 and be "high level" issues. That is why I am changing them to be
FEATUREs with P2. If you think I've done wrong change, please update the issue
and internal documents.

Comment 15 Jiri Rechtacek 2003-08-26 15:52:56 UTC

This task is covered over by other issues:
part 1) issue 35787 and issue 23116
part 3) issue 35787
part 3) issue 7706
part 3) issue 25561
It close as duplicate (e.g. 7706) to clear the duplicates between
enhancements and make well-arranged.

*** This issue has been marked as a duplicate of 7706 ***

Comment 16 Jiri Rechtacek 2004-03-23 08:26:32 UTC

Replacement duplicate with dependency.

Comment 17 Jiri Rechtacek 2004-05-07 10:23:01 UTC

All depended issue are either fixed or wont fix. I'm going to close as
solved as duplicate of anyone depended issue.

Comment 18 Jiri Rechtacek 2004-05-13 09:28:55 UTC


*** This issue has been marked as a duplicate of 23116 ***