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: | Cannot rename a file's extension | ||
---|---|---|---|
Product: | platform | Reporter: | David-john Burrowes <davidjon> |
Component: | Data Systems | Assignee: | Jaroslav Tulach <jtulach> |
Status: | CLOSED DUPLICATE | ||
Severity: | blocker | CC: | jglick, mmirilovic, pfelenda, pjiricka, pnejedly, sherold |
Priority: | P4 | ||
Version: | 4.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
David-john Burrowes
2004-06-11 00:56:52 UTC
Not a problem of explorer, it works accordingly to Nodes behind it and this actual editing policy is caused by DataNodes *** Issue 44747 has been marked as a duplicate of this issue. *** The situation is following: what is renamed depends on the underlying DataObject and what it returns as its name. The default behaviour in DataObject class is to return filename without extension. But it can be overriden as demonstrated by DefaulDataObject (which is used for all unrecognized files). Here are some solutions: #1) change default behaviour of DO.getName() to return filename including the extension. Danger here is that it might not be wanted in all cases. I'm not sure about the impact. #2) change it per DataObject - ask owner of JavaDO, HTMLDO, JSPDO, etc. to change the behaviour similarly as DefaultDO does. Safe but more work. #3) variation of #1: use IDESettings property "showExtensions" and based on that property return extension from DO.getName or not. #4) do nothing, it is just a P4 At the moment I prefer #2 (or #4) which means that this issue is WONTFIX and individual issues for each module must be filed. #3 could perhaps be reasonable compromise and should be easy to do too. Opinions? DataObject.name is not relevant here (and changing its behavior is a really bad idea - will break all sorts of things you don't know about). DataNode.name is what is used during renames. I am probably in favor of changing the default for DataNode.name to be dobj.primaryFile.nameExt. I assume that the loader pool is already smart enough to rescan the type of the file if you rename it. Be very careful however with code which selects nodes in various tabs. Since there is no API to do this safely (issue #7551), various hacks are scattered around the code base to do it. Most are inadequately tested and sometimes may not be expecting a name with extension (meaning it is already broken for DefaultDO's - which I have corrected at least once). Generally, expect to introduce about ten new minor bugs as a result of fixing this. Would not recommend it for 4.0. OK. *** Issue 40853 has been marked as a duplicate of this issue. *** The default data object shows that such behaviour is possible. If we want other types of objects to support it, let's change them as well, but changing directly the DataNode is a bit inconsistent. I can add new constructor to DataNode or MultiDataObject accepting boolean saying whether the name should be full or without extension. But that requires changes in each of affected modules. Possible, but if really needed, fire individual bugs for each module you want to change and make it depend on this issue. I'll provide the updated API then. Couldn't you introduce a separate call, renameWithExtension(String)? The UI code that actually renames the DataObject will detect a . character and ask if you want to actually change the extension, and choose whether to run the old rename code or renameWithExtension(). If you do rename with extension, of course the old DataObject is invalidated (maybe check it for EditorCookie and close any open editors over it before the rename?). At least, it's a way to do it without changing the behavior of existing code. Wouldn't this issue deserver raising to P2 or at least to P3? This is something I miss in the IDE almost every other day. Please correct me if I missed something, the current proposal looks like this: If the tail of the String after the last . is different, it will ask you if you want to change the file type and you can choose yes or no. If you tried to rename Foo.java to Foo.html, you are asked if you want to change it to Foo.html.java or Foo.html; if you entered Foo.html.java you will not be asked if you want to create Foo.html.java.java I have to say, I would be tempted to file a usability issue against it, if it was implemented like this. Changing an extension is a very simple operation from user point of view and displaying any unnecessary dialog would be really annoying. I understand that showing the name with extension while renaming, which would be the ideal solution IHMO, would require an API change which could break a lot of stuff. Well, what about this... we will show a name without extension, user changes the name an we will check whether the new name contains a '.' character. If it does, we will take it as a new name with a new extension, if it does not, we will change just the name. Here is an example: old name displayed name entered name new name foo.java foo foobar foobar.java foo.java foo foo.bar foo.bar foo.java foo fool.bar.java foo.bar.java foo.java foo foo. foo. Re. sherold's suggestion: need to also define behavior in case old name (sans extension) contained dots, e.g. "foo.bar.html" renames how? That is the tricky part, and probably why Tim suggested a dialog to clarify. A suggestion was made to always show full name in rename dialog/in-place rename, but select all but the extension, so that "normal" basename renames remain easy, but extension changes are also simple. Would require a new API method in Node; probably compatible. Easy to implement in Rename dialog, but not so sure about in-place rename - need to prototype in TreeViewCellEditor. Also need to consider the problems associated with changing the extension of a modified file (which currently would discard user changes without prompting). And API implications are not clear. For a normal basename rename, we need to call DataObject.rename(), which correctly handles modified files, keeps open editor windows active, etc. For a rename which would change type, we would need to disable this for data objects with more than one file entry (e.g. form files, and sometimes property files), and we would need to call FileObject.rename(), which would probably force a data loader refresh on the file (to change type). But then there are loaders like DefaultDataObject which can change extension without changing type, in which case DataObject.rename() would be more appropriate... but how would we know that? Tim's suggestion of adding DataObject.renameWithExtension may be the best approach but a lot of details need to be worked out first. Well, I see it's tricky ;) Thanks for pointing that out. So it is the following use-case: old name displayed name entered name new name foo.bar.html foo.bar foo.bar ? foo.bar ? foo.bar.html I would say that from my point of view some dialog would be acceptable in this case, since this is not something that I would deal with every day. The same would apply when renaming 'file' which represents multiple files e.g. form backed java files. Anyway, I would vote for any solution that would handle the most common use-cases without any needless dialog. I think is sup of issue 27444, isn't it ? Yes, same. *** This issue has been marked as a duplicate of 27444 *** verified/closed |