Bug 27444 - [50cat] Permit changes to file extension
Summary: [50cat] Permit changes to file extension
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Data Systems (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker with 2 votes (vote)
Assignee: Jaroslav Tulach
URL:
Keywords: UI
: 27210 44739 67699 73762 157322 (view as bug list)
Depends on: 7551 16389
Blocks: 38870
  Show dependency tree
 
Reported: 2002-09-19 13:52 UTC by Petr Jiricka
Modified: 2014-05-26 06:27 UTC (History)
9 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
First draft of implementation (4.72 KB, patch)
2008-07-17 22:00 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Jiricka 2002-09-19 13:52:22 UTC
When file extensions are visible in filesystems, the 
Rename... action on a file should allow changing the file 
extension. The current approach creates UI inconsistency 
between the explorer view and the Rename dialog.

To reproduce:
1. In Tools -> Options -> IDE Configuration -> System -> 
System Settings, change "Show File Extensions" to true.
2. In filesystems, choose any Java file (which is not a 
directory) and select "Rename..." in the popup menu.
3. The dialog will only show the file name without 
extension, and will not allow changing the extension.
Comment 1 Marian Mirilovic 2002-09-27 09:54:16 UTC
Rename action and possibility to change type of data object ?!
Comment 2 Marian Mirilovic 2003-01-06 16:16:38 UTC
I have changed version from 4.0 dev to S1S 4.2 (Nevada).
Comment 3 David Simonek 2003-05-12 15:24:21 UTC
Evaluation:
Such feature IMO makes sense only when there is 1-1 relationship
between items in explorer and files on disk.
In current situation, it's not clear what should such action do -
change extension of all files in MultiDataObject - not even possible.
Change extension of primary file only - not consistent with how rename
usually works - regular rename action for java and forms renames all
files, using the fact that names of .java and .form files without
extensions are equal.

Therefore I'm changing to task, cc'ing maintainer of data systems. I'm
proposing to solve this issue together with data system rewrite, AFAIK
it will have 1 to 1 mapping. Correct me if I'm wrong.
Comment 4 David Konecny 2003-05-12 16:09:30 UTC
On the DS level there will be 1:1 mapping. But it is possible that
presentation layer (ie. explorer with a look which groups objects)
will be similar.
Comment 5 dmartin01 2004-01-15 23:55:54 UTC
*** Issue 27210 has been marked as a duplicate of this issue. ***
Comment 6 jmaurus2 2005-03-12 11:37:51 UTC
At least in the "Files"-View this should be possible. This bug makes it almost
unbearable to use Tapestry with Netbeans, because even though you can add "jwc",
"application" and "page" to the file extensions for XML Objects in the
Options-dialog, you then can't create files with these extensions as XML files,
as the wizard insists on adding ".xml" to the filename.

Even worse, if you create .jwc files as "Empty files", they won't be recognized
as XML, so you loose all XML-editor capabilites, but there's no visible
difference between a "XML Object" file and a "emtpy file Object" file besides
the icon. This is a little hard to grasp, even for delevopers.

So creating a Tapestry-XML file now requires 4 steps: creating the file, closing
it, renaming it on the command line, reopening it.

I just spent 4 hours of my workday clicking through the whole Options-dialog,
and right-clicking on the file in the Explorer view in disbelief. Please fix
this, it drives me crazy. 

A feasible work-around might be to add an item to the FAQ, possibly involving an
explanation on how to register your own filetypes and extensions in the "create
file"-wizard?
Comment 7 jmaurus2 2005-03-12 11:50:32 UTC
Apologies for the comment-spam. Now I understand that this issue goes more
deeply than I thought. An addition to the FAQ might be a good idea anyway.
Comment 8 David Simonek 2005-05-04 12:06:47 UTC
Passing this enh to explorer guys, please pass further if I'm wrong, thx.
Comment 9 Petr Nejedly 2005-05-04 14:27:06 UTC
In it not a problem of explorer, explorer just does what DataNode tells it.
Comment 10 Jesse Glick 2005-11-10 05:19:00 UTC
*** Issue 67699 has been marked as a duplicate of this issue. ***
Comment 11 Marian Mirilovic 2006-03-28 09:36:52 UTC
*** Issue 73762 has been marked as a duplicate of this issue. ***
Comment 12 Jesse Glick 2006-03-28 17:43:50 UTC
*** Issue 44739 has been marked as a duplicate of this issue. ***
Comment 13 Jaroslav Tulach 2006-07-27 15:56:37 UTC
Standa is currently working on Save As support, which would in fact also solve 
this problem. Reassigning to him, to close this issue when he integrates his 
save as.
Comment 14 Jesse Glick 2006-07-27 18:12:07 UTC
You mean that Save As would provide an easier workaround for lack of full file
rename than going into a native file browser. Not a "solution". To rename
foo.xml to foo.jnlp you would need to open foo.xml, Save As, enter foo.jnlp,
then delete foo.xml. And this will not work correctly with Subversion.
Comment 15 Stanislav Aubrecht 2006-07-28 09:25:13 UTC
SaveAs will be available also for un-opened files, i.e. select a file in e.g.
Projects view and choose 'Save As' from File menu.
but the original file does remain untouched...
Comment 16 Petr Jiricka 2008-07-17 11:38:07 UTC
In NetBeans 6.5, the situation is slightly improved in that you can now easily register .jwc files to be recognized as
.xml files (through Tools -> Options -> Miscellaneous -> Files, modulo bug #140486 that I am seeing right now), so the
workaround is to rename the file manually outside NetBeans and associate its extension in NetBeans so it is treated as
the desired file type.

However, the main problem still remains - one can not change extension when renaming files. What can be done to solve
it? Is it enough to get rid of all objects which still use multiple files per file, and deprecate/kill this ability?
Right now I am aware of .properties and .form/.java objects using multiple files per object, is there anything else?

Or, could we allow changing the extension in the case when the particular object being renamed does not consist of
multiple files?
Comment 17 Jesse Glick 2008-07-17 20:53:23 UTC
To Petr's last suggestion: I think it would suffice for MultiDataObject.get/setName to cease to strip off the file
extension. (If you happened to rename X.java -> X.notjava while X.form exists, then you will see a new node appear for
X.form - which is what you requested, so I don't think it's a bug.)
Comment 18 Jesse Glick 2008-07-17 22:00:06 UTC
Created attachment 64905 [details]
First draft of implementation
Comment 19 Jesse Glick 2008-07-17 22:10:59 UTC
The attached patch does let you rename the file extension. (At the node level, rather than data object level, since I
think that is much less likely to be seen as incompatible.) It has some problems:

1. Java rename refactoring is invoked with the wrong name.

2. If you do rename a file's extension to something completely different, the IDE fails to refresh the display to show
the new file type. It uses the same icon, and also there can be problems if the original DataNode impl expected its file
to have certain properties. I cannot figure out how to force a refresh: DataObject.valid = false does not work,
super.destroy() does not work, even setting a new FolderChildren on the parent node does not work. Something in
Datasystems persists in keeping the same node for the file. Might be related to recent "laziness" work in nodes.
Comment 20 Jesse Glick 2008-07-17 22:13:24 UTC
DataLoaderPool.setPreferredLoader(prim, null) does not work either - it does cause the folder tree to collapse, but the
same old node (with the new file extension visible) is still shown when you reexpand it!
Comment 21 Antonin Nebuzelsky 2008-11-13 13:35:22 UTC
Reassigning all openide/data systems issues to the new owner jskrivanek.
Comment 22 sushkov 2008-11-21 19:08:32 UTC
I'm trying to switch from Komodo Edit to Netbeans for web development.

Guy's this feature is a bug!!! A very silly and annoying bug.
Didn't you learn already on M$ mistakes?

Shame on you...
Very sad. :(
Comment 23 Antonin Nebuzelsky 2008-11-25 23:49:30 UTC
Thanks for asking us to reevaluate. ;)

Changing TM to TBD and asking the jskrivanek to evaluate based on the recent comments/ideas from this summer.
Comment 24 Quality Engineering 2008-12-23 14:32:28 UTC
This issue had *3 votes* before move to platform component
Comment 25 Jiri Skrivanek 2009-01-23 08:47:53 UTC
*** Issue 157322 has been marked as a duplicate of this issue. ***
Comment 26 Jiri Skrivanek 2009-02-26 10:38:07 UTC
Based on the patch by Jesse I implemented this in DataNode and JavaNode. Now it is possible to change extension when
renaming nodes. If you do inplace editing (F2) of java node and don't change the extension, java refactoring is called.
Refresh is enforced by invalidation of underlying DataObject. If you change extension of MultiDataObject (like form),
only primary file is changed and children are refreshed. If you know better way, how to reliably refresh children,
please let me know.

FolderList folderList = FolderList.find(prim.getParent(), true);
folderList.getChildren(); // need to be here - refresh is not enough
folderList.refresh(); 

http://hg.netbeans.org/core-main/rev/38b6f9f65a97
Comment 27 Jesse Glick 2009-02-26 15:44:36 UTC
ViewTest in ant.freeform fails; View.findPath must use FileObject.getNameExt(), not .getName(). You need to look around
at various code that uses NodeOp.findPath and FileObject.getName() since it is probably not now going to work. In
particular, WebLogicalViewProvider.findNodeIn* methods probably need to be changed, and there may be other cases in
other project types.

Issue #7551 would offer a better way to centralize logic like this. Some day I will propose an API here.

BTW java.source does not react very well to a change from *.java -> other -> *.java. It does not update error badges.
Comment 28 Quality Engineering 2009-02-27 10:32:46 UTC
Integrated into 'main-golden', will be available in build *200902270313* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/38b6f9f65a97
User: Jiri Skrivanek <jskrivanek@netbeans.org>
Log: #27444 - Allow to change extension when renaming nodes.
Comment 29 Jiri Skrivanek 2009-02-27 12:47:08 UTC
I didn't find any other solution. There is an inconsistence that getName() for some nodes representing a file on disk
return file name with extension and some nodes return only base name. Likely all sub classes of DataNode and all usages
of DataNode.getName() should be fixed. Maybe also other classes as Jesse pointed out. 
Comment 30 Jiri Skrivanek 2009-03-05 08:15:56 UTC
As a temporary solution I added a new property to DataNode which allows to change extension. It is not ideal because it
is a little bit hidden but it works for now. Thanks to jtulach for this idea.

http://hg.netbeans.org/core-main/rev/5eecce73b2a8
Comment 31 Jesse Glick 2009-03-05 08:21:21 UTC
Interesting. UI is maybe not ideal, but probably a lot safer.

BTW DataObject.PROP_EXTENSION is an API change, one you probably don't need or want.
Comment 32 Jaroslav Tulach 2009-03-05 15:28:57 UTC
Instead of
+                try {
+                    // Invalidate current DataObject which enforces refresh
+                    // and new DataObject will be created.
+                    obj.setValid(false);
+                } catch (PropertyVetoException ex) {
+                    // ignore
+                }
you can simply call obj.dispose()


DataObject.PROP_EXTENSION is not only unnecessary, it seems wrong. According to NetBeans practices, it should mean 
there is a getExtension() on DataObject. There is no such getter as far as I can tell.
Comment 33 Jiri Skrivanek 2009-03-06 08:13:20 UTC
OK, PROP_EXTENSION removed from API and DataObject.dispose() used. Thanks.
Comment 34 Quality Engineering 2009-03-06 09:28:51 UTC
Integrated into 'main-golden', will be available in build *200903060201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/5eecce73b2a8
User: Jiri Skrivanek <jskrivanek@netbeans.org>
Log: #27444 - Show property "Extension" which allows to change extension.
Comment 35 Quality Engineering 2009-03-07 09:48:46 UTC
Integrated into 'main-golden', will be available in build *200903070353* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/dea1b9f9ed15
User: Jiri Skrivanek <jskrivanek@netbeans.org>
Log: #27444 - Use DataObject.dispose() instead of setValid(false).
Comment 36 Petr Jiricka 2009-07-21 08:29:58 UTC
Is there any part of this that still need to be addressed? If there is, then I suggest filing it as a separate issue.
Either way, this should probably be closed as FIXED.
Comment 37 Jiri Skrivanek 2009-07-27 13:46:50 UTC
Now it is possible to change file extension only through property sheet. Change by rename action or inplace editing is
not allowed.
Comment 38 Jaroslav Tulach 2010-04-07 04:30:36 UTC
Jirka forgot to mark the bug as fixed.
Comment 39 Marian Mirilovic 2013-08-01 03:53:43 UTC
*** Bug 122190 has been marked as a duplicate of this bug. ***
Comment 40 sproger1 2014-05-02 16:48:22 UTC
This is still not yet fixed. We should be able to rename the file extension on the node or from the right-click rename action. Renaming in the properties window is still very inconvenient and is hidden to most users(since no one would intuitively think of trying that).

At least make it an option, that we can turn on or off.


I am a developer of a Netbeans RCP app and this is annoying to users of my app. I will override/replace that behaviour (but, I really should not have to).

I understand the desire to prevent users from accidentally removing/change '.java' at the end of a file, but the netbeans developers SHOULD understand that that is not the only use case. 

Please allow renaming of file extensions everywhere as an option.
Comment 41 Jaroslav Tulach 2014-05-26 06:27:35 UTC
Renaming in the properties is a solution. It may have its drawbacks, but that is all we will provide in the core.

In case you want to provide an optional support for renaming with right-click on the node, I suggest you to extend NetBeans yourself. Write a module that suite your needs and use it.