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.

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. 

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.

> 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.

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
expected.

(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.)

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. 

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.

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.

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
name="inc"/>. 

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.
         

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...

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.

First, I think we would like to have api like: registerExtension(String extension, String mimeType).

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)? 

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.

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).

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). 

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.

I'm sorry, the mentioned issue in my last comment is issue #137734. Wrong copy paste.

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 java.io.File) 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.