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 139174 - New File wizard should allow to overwrite default extension
Summary: New File wizard should allow to overwrite default extension
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Dialogs&Wizards (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Stanislav Aubrecht
Depends on:
Reported: 2008-07-07 20:40 UTC by Petr Pisl
Modified: 2010-10-07 10:41 UTC (History)
6 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Petr Pisl 2008-07-07 20:40:40 UTC
This comes from PHP, where user can create new PHP files with many extensions. Partially it can be solved just in the
PHP new file wizard, but then it will not be consistent with other wizards. 

There are two usecases:
1) User wants to create new php file with non default extension, like .tcl
2) User wants to create a php file through non php wizard. Like css file, which will contain  php code.
Comment 1 Lukas Hasik 2008-07-08 07:31:49 UTC
IMHO, it works as it was designed now. I'm changing it into enhancement.

This case can be valid for PHP developers but the most of other users expect the same extension for the same file type.
I don't see any reason for a generic approach in the new file wizard.

I'm cc'ing Jano as UI expert.
Comment 2 Petr Pisl 2008-07-08 12:09:32 UTC
We need this for PHP IDE. What I expect is a decision that it's ok to provide this functionality only in PHP or it will
be solved generally. If this is enhancement then it should be P2. 
Comment 3 jrojcek 2008-07-08 12:25:59 UTC
As the most pressing need for this feature is in PHP, I would suggest to do it for PHP files only (for 6.5). What are the other files, the user may want to change 
extension (it probably isn't needed for Java files)? If we had a list of all file templates where this is needed, than we can talk about what's the best approach 
and who should take care of that.
Comment 4 Antonin Nebuzelsky 2008-07-09 17:44:04 UTC
> it probably isn't needed for Java files

IMO it is even undesirable to let the user change the extension for Java files.

> a list of all file templates where this is needed, than we can talk about what's the best approach

+1 from me

I tend to agree with Jano that php file template gets this resolved individually for 6.5.
Comment 5 Jesse Glick 2008-07-11 15:26:43 UTC
Agreed, PHP wizard itself should offer this choice. I don't think it's desirable for most wizards. At least it would
need to be implemented pretty carefully to make sure that the chosen extension would yield the same MIME type as is

(Why would you name a PHP file *.tcl?! It would not work in such a case. If you wanted to make a TCL file, you could use
its template, or just use the generic File template which already lets you enter an extension.)
Comment 6 Petr Pisl 2008-07-11 16:20:45 UTC
I agree that it will be handled by php wizard. Unfortunately the wizard will inconsistent with other files. 

> Why would you name a PHP file *.tcl?
Basically the enhancement comes from our users. There are many files, which can be proceeded by the php. We are not able
to find out all extension, which we should support, because it depends also on the company frameworks. So let say that
they continue in a project, which use .dwt extension for php templates. You need to create new php files with .dwt
extension not .php. Sure there is a workarround through the generic File template, but it is not so intuitive. 

Even if we know all the extensions, we don't want to provide many php templates (one template per one php extension). By
default the php mimetype has now 7 registered extensions. 
Comment 7 Jesse Glick 2008-07-14 21:16:51 UTC
Well it seems like PHP files really behave a bit differently than other kinds of files in the IDE so I don't see the
inconsistency as unnatural.
Comment 8 Petr Jiricka 2008-07-15 18:47:18 UTC
Radek implemented the functionality specifically for the PHP file wizard, however, from what he said, the infrastructure
does not make this particularly easy and more support from the base wizard would be useful. Radku, can you please let
the core team know what improvements in the infrastructure you would find useful? Thanks.
Comment 9 rmatous 2008-07-16 08:15:02 UTC
From php user point of view we find following behavior to be ideal solution: 
user can choose name of file including extension. If extension not handled as php file (GsfDataObject, mimitype:
text/x-php5) offer him to register extension (as file association in Tools/Options).

I haven't implemented it yet as described (just halfway - the code checks whether user put in known php extension, but
user cannot register not known extension yet). 

I implemented it this way (389a2339973e) - description in short: stripped "php" extension from all our file templates to
achieve createFromTemplate to prevent from completion like myfile.phtml.php. Then I modified our declarative mime
resolver to resolve these templates without extension as text/x-php5 (see the commit for more details). To find out
whether user put in known php extension I've created fileobject with such extension on memoryfs  and ask this fileobject
for mime type.

For registering extension I would probably need to rewrite content of our mime resolver and put in new line like  	<ext

Probably I would also need to implement myself the wizard panel (similar like SimpleTargetChooserPanel) to implement it.

Definitely the impl. isn't much straightforward. So, any advice, api would be welcomed.
Comment 10 Antonin Nebuzelsky 2008-07-16 09:43:11 UTC
Jirko, discuss this with Radek and summarize the enhancements we could implement in New File Wizard and in MIME resolver
API. Most probably we will plan these for post-6.5, but some might be fixed even now...
Comment 11 Petr Pisl 2008-07-16 11:02:37 UTC
One more, which we have to solve. When you invoke new file wizard, then the name of new file is selected by default. In
our case the name and extension are selected. But the goal state is to have selected only the name without the extension.
Comment 12 rmatous 2008-07-16 11:14:43 UTC
First, I think we would like to have api like: registerExtension(String extension, String mimeType).
Comment 13 rmatous 2008-07-16 15:48:17 UTC
After discussion with Jarda we will go this way:
- revert our changes (handling ${PHP} freemark and resolving it as mime type by declarative resolver, btw: problematic
see #140308, #140303 )
- we will add our impl of mime resolver that will look for <?php marks (taking into account that it doesn't need be
first characters in the document - e.g. phtml files) 
- so we will have two resolver 1. the declarative one (because of tools/options file associations to work) and 2. the
one described above

We will require api changes (probably somehow somewhere in fs api) like these for 6.5:
- void registerExtension(String extension, String mimeType) 
- Collections<String> getRegisteredExtensions(String mimeType)

Is it OK?

The other problem is duplicating templates with Template Manager. We have our impl.
WizardDescriptor.InstantiatingIterator which is registered as attribute "templateWizardIterator". After duplicating
template is this attribute lost - just a bug, I think.

From UI point of view we can implement our own wizard panel (not sure if we find time for doing it)? 

Comment 14 Jesse Glick 2008-07-16 16:07:43 UTC
Collections<String> getRegisteredExtensions(String mimeType) sounds similar to the method List<String[]>
getExtensionsAndMIMETypes(FileObject fo) I proposed adding to MIMEResolver in issue #138846, which Yarda rejected in
favor of an implementation dependency (core.ui -> openide.filesystems). Since as I understand it this kind of method is
only needed for communication with the File Types option panel, probably it should be kept out of openide.filesystems
entirely. (We could consider splitting this panel out of core.ui into its own module - e.g. filesystems.ui? - with a
friend package exported to the PHP wizard.)

It is indeed a bug which should be filed separately if pressing Duplicate in Template Manager causes
instantiatingWizardIterator to be lost on the copy.
Comment 15 Jesse Glick 2008-07-16 18:05:37 UTC
Maybe I'm missing something, but: if you can anyway have a resolver which recognizes any PHP file by the presence of
"<?php", why do you need to do anything else? Neither the user nor the infrastructure then needs to register any special
extensions; you can name your files anything (so long as the new file does not use an extension whose resolver is
earlier than the PHP resolver).
Comment 16 rmatous 2008-07-17 07:51:35 UTC
I guess, you understand it pretty well Jesse. I'm a bit disoriented on the way to cheese in the maze :). Really if we
have reliable own mime resolver impl. without perf.problems, then no extension resolving is necessary: one hypothetical
exception is if file didn't exist yet (then fileobject doesn't exist) and second one exception is performance - when you
need to make the decision about mime type for huge number of files like indexing (PHPIndexer in php.editor), Petr Pisl
and Tomasz Slota mentioned it as a problem (comparing just extension and avoiding File->FileObject conversion with mime
reolution reportedly brings huge perf.benefit). 
Comment 17 Petr Pisl 2008-07-17 15:30:17 UTC
Regarding the indexing, there is issue #139174, which required the functionality and describes it. Problem is that
creating FO was to slow, during indexing big bunch of files. The most fast way is still checking extension. But for this
we need to know the extensions. Unfortunately I haven't time to try the attached patch in #139174.
Comment 18 Petr Pisl 2008-07-17 16:04:50 UTC
I'm sorry, the mentioned issue in my last comment is issue #137734. Wrong copy paste.
Comment 19 Jesse Glick 2008-07-17 22:39:13 UTC
Possible trick to get decent performance while keeping some flexibility:

1. Have resolver which recognizes *.php (and any other clearly official extensions) fairly early in pool (so e.g. folder
expansion is quick for typical user).

2. Have a resolver which recognized "<?php" later in the pool, so unusual extensions work too.

3. Have the indexer only scan for *.php (as during initial scan of a source root, plus files of other
extensions directly mentioned e.g. in include statements (not sure about PHP syntax here!).

4. Have PHPDataObject in constructor inform indexer that this is a PHP file if not named *.php. Thus files with unusual
extensions but PHP contents will get indexed too if you actually browse to them.