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.
Summary: | [50cat] Permit changes to file extension | ||
---|---|---|---|
Product: | platform | Reporter: | Petr Jiricka <pjiricka> |
Component: | Data Systems | Assignee: | Jaroslav Tulach <jtulach> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | anebuzelsky, dkonecny, dstrupl, ivar, jglick, jtulach, mmirilovic, pnejedly, sherold |
Priority: | P3 | Keywords: | UI |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 7551, 16389 | ||
Bug Blocks: | 38870 | ||
Attachments: | First draft of implementation |
Description
Petr Jiricka
2002-09-19 13:52:22 UTC
Rename action and possibility to change type of data object ?! I have changed version from 4.0 dev to S1S 4.2 (Nevada). 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. 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. *** Issue 27210 has been marked as a duplicate of this issue. *** 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? 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. Passing this enh to explorer guys, please pass further if I'm wrong, thx. In it not a problem of explorer, explorer just does what DataNode tells it. *** Issue 67699 has been marked as a duplicate of this issue. *** *** Issue 73762 has been marked as a duplicate of this issue. *** *** Issue 44739 has been marked as a duplicate of this issue. *** 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. 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. 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... 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? 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.) Created attachment 64905 [details]
First draft of implementation
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. 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! Reassigning all openide/data systems issues to the new owner jskrivanek. 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. :( 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. This issue had *3 votes* before move to platform component *** Issue 157322 has been marked as a duplicate of this issue. *** 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 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. 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. 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. 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 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. 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. OK, PROP_EXTENSION removed from API and DataObject.dispose() used. Thanks. 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. 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). 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. Now it is possible to change file extension only through property sheet. Change by rename action or inplace editing is not allowed. Jirka forgot to mark the bug as fixed. *** Bug 122190 has been marked as a duplicate of this bug. *** 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. 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. |