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