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 40894 - Do not use loaders in API
Summary: Do not use loaders in API
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Infrastructure (show other bugs)
Version: 4.x
Hardware: All All
: P1 blocker (vote)
Assignee: Jiri Rechtacek
Depends on: 42192
Blocks: 40703 41535
  Show dependency tree
Reported: 2004-03-10 10:21 UTC by Jaroslav Tulach
Modified: 2005-12-14 16:32 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2004-03-10 10:21:33 UTC
I've observed occational references to
org.openide.loaders. Looking closer to this I have
found out that those are usually reference to
TemplateWizard and its Iterator. 

I am convinced that there is no real reason for
this  other than convinience and anyway
TW.Iterator does not seem to be suitable well for
creation of new project, for example, and that is
why I think the buildsys apis should be data
systems independent. (I know that physical view is
based on them, but that is not my concern, that
can stay or be replaced).

If I should suggest some replacement, for example
for iterator to create new Project, I would create

interface ProjectIterator {
  // with needed methods like init,deinit,install
  // and some communication to obtain logical
  // project name, physical location, etc. In the
  // best situation supporting extensibility.

I would suggest to continue to use
TempalateWizard, just modify the way how templates
are registered in the /Templates/Project
directory. There are two choices:

<attr name="templateWizardIterator"
methodvalue="org.nb.api.project.ui.Wizard.default" />
<attr name="projectIterator" newvalue="..." />

which is simple, works immeditatelly and has just
two problems: it still shows the
templateWizardIterator and it uses methodvalue,
which is to be deprecated in future. Thus the
nicer alternative would be to define your own XML
type and register projects by a descriptive file:

<file name="jnlp.xml" url="jnlp.xml" >
   <attr name="template" boolvalue="true" />

and in the jnlp.xml have:
<!DOCTYPE project-template PUBLIC "..." >
  <iterator classname="..." />
  <!-- other stuff if needed -->

This file would be automatically processed
(XMLProcessor or Environment.Provider are currnen
possiblities) and convert ProjectIterator into
TemplateWizard.Iterator, so the API would remain
completelly clean from the loaders stuff.

I like the second suggestion a bit better, but I
am not going to request particular impl, this is
just suggestion. The request is to get rid of
loaders package in API (javadoc for sure, layers
and other apis if possible).
Comment 1 Jesse Glick 2004-03-10 13:17:35 UTC
The main reason to use TemplateWizard.Iterator was simply that so many
existing wizards already implement it, and in order to get rid of use
of loaders throughout the APIs we would have to replace these anyway.
I.e. I was expecting a different effort to work on creating a
loader-less template API, and not for promo-D.

To remove the org.openide.loaders.* dep in the API for creating
templates means that every module with a custom wizard will need to be
rewritten. Perhaps not such a big deal, but I wanted to avoid such a
big change just in order to support project-sensitive templates.
Comment 2 Jaroslav Tulach 2004-03-10 13:38:36 UTC
What are the cases when TemplateWizard.Iterator is used in API? I am
aware of one: when creating new project. That usage does not need any
existing modules rewrite, the TemplateWizard usage there is artificial.

What are the other cases when it is used?
Comment 3 Jesse Glick 2004-03-12 15:57:10 UTC
Will need to look at this. There are really two issues:

1. Currently new project creation requires that the wizard be in
Templates/ and use a TW.I, just like any other template. This is
completely consistent with creation of many other kinds of objects in
the IDE and I am not sure I want to do something wildly different for
project creation just because you want to remove deps on loaders. We
may need to have a general (buildsys-independent) addition to the
wizard API and set of conventions as to where to register wizards. We
need to do this anyway for many other kinds of wizards.

2. Creation of new files. Here the API currently uses TW.I for two

a. Compatibility with existing templates in the Templates/ dir with
custom wizards. It is possible there is some way to retain
compatibility with these without exposing o.o.loaders.* in the public
API. Or, more likely, we can just forget about trying to retain wizard
compatibility for such templates; very likely they would need to be
rewritten anyway to match the revised user model.

b. TW.I already exists and describes what is needed to create new
objects from template. Without it, will just need to create a new
interface which looks more or less identical but is in a different
package. Not a big issue.

I will concentrate on #2. I am not convinced #1 should be solved here;
rather, when we make a real effort to remove Datasystems, we should be
providing a reasonable alternative for special (non-file) "template"
wizard registration.
Comment 4 Jesse Glick 2004-04-03 00:30:32 UTC
I think Petr is already working on this and it should be possible to
remove all refs to Datasystems.

Re. project creation (also Java platform creation), there will be a
new interface such as WizardDescriptor.InstantiatingIterator which
will look similar to TW.I but not refer to Datasystems, e.g.

public interface II extends Iterator {
    // throws IOException? probably unnecessary, TBD
    Set/*<Object>*/ instantiate();
    void initialize(WizardDescriptor d);
    void uninitialize(WizardDescriptor d);

We can use the same for file templates, so that the
templateWizardIterator attr (e.g.) would be expected to be of this
type. It may be possible to provide a bridge for TW.I instances as
well, though this is probably not very high priority since I would
expect most existing custom wizards would need to be rewritten anyway.

Comment 5 Jiri Rechtacek 2004-05-04 13:21:41 UTC
WizardDescriptor.InstantiatingIterator has been created and
implemented by java/project/NewJavaFileWizardIterator, modules can
declare this iterator in its layer.
Comment 6 Jesse Glick 2004-05-04 17:58:33 UTC
Jirka, next time please paste or attach the commit log into the issue
report for future reference.
Comment 7 Jesse Glick 2004-05-04 18:09:05 UTC
I'm not sure the original request is actually fixed here. :-)
NJFWI.instantiate returns Set<DataObject>, which was exactly what we
did not want - we want to return Set<FileObject>.

Also IMHO the new file wizard infrastructure should be responsible for
running default actions (i.e. open in editor) of newly created files,
not the particular wizard.

Co Hrebejk?
Comment 8 Jesse Glick 2004-05-04 18:15:05 UTC
I am reopening pending an answer to the last comment. I see that
NewFile just calls wd.instantiate and discards the result. It should
IMHO expect a Set<FileObject> and open them all.
Comment 9 Jiri Rechtacek 2004-05-05 10:18:57 UTC
Log: #40894: NJFWI returns set of FileObject instead of DataObject
Checking in
new revision: 1.6; previous revision: 1.5
Comment 10 Marian Mirilovic 2005-12-14 16:32:00 UTC
no additional informations for long time - closing