Community
Participate
Working Groups
Unlike in Eclipse R2.1.n, opening a file in the CVS repository gives the editor an input org.eclipse.team.internal.ccvs.ui.RemoteFileEditorInput whose getFullPath() method returns the full path with the version number appended to it!? This is incorrect, the version should only be appended to #getName(), i.e., for display purposes. Having the version appended to the returned IPath causes various problems, for example getFullPath().getFileExtension() will return the ".2" rathen than ".properties" in the case of "dev.eclipse.org\home\eclipse\plugin.properties 1.2"
In general, clients should not deduce anything from the path of an IStorage. The spec for IStorage says that what is returned by getFullPath() depends on the implementor (i.e. has no meaning other than it is a full path that can be displayed to the user). The spec also states that the name should be the last segment of the full path which it currently is. Perhaps if you described what you are trying to do, we can come up with a proper solution.
1.- My editor supports several parsers (for syntax coloring, etc.) - it supports various editor "extensions" (in its plugin.xml), and then looks itself at the file extension in order to determine the parser to use. When its editor input is an IStorageEditorInput, it uses IStorage storage = ((IStorageEditorInput)editorInput).getStorage(); IPath fullPath = storage.getFullPath(); in order to determine the name -> extension -> parser... Having the revision number now part of the IPath causes this to fail. Now I'd have to handle a special case of editorInput.getClass() being org.eclipse.team.internal.ccvs.ui.RemoteFileEditorInput, which will require my plugin.xml to have an extra dependency on the cvs plug-in, etc... 2.- RemoteFileEditorInput has a #getContentType() method, but this is not part of IStorageEditorInput, so it requires special-case handling as well... 2.- Is there a compelling reason to put, in Eclipse R3.0, the version number in the IStorage#getFullPath(), which was not there in R2.n? 3.- IPath#getFileExtension() clearly also suffers from this change (see my original problem description) - should a bug be opened against it?
The revision number is added to the full path for the same reason it is added to the name: as a way to differentiate one revision of the same file from another. As Imentioned before, the IStorage spec clearly states that the format of the path and name are up to the implementor and can even be null (i.e. the client cannot deduce anything from it. Also, the IPath spec just says that the file extension is determine using everything after the last period. It doesn't state that all uses must make sure that what is there is a meaningful extension (even though this may seem like a reasonable assumption). However, I see you problem. Unfortunately, there is no API that will reliably give you the file extension that was used to obtain the editor input for an IStorage. This seems to me like a bug in the Platform Text component. One possible workaround would be to register a different class for each extension thus allowing you to deduce which extension was used to obtain the editor.
Reopeong to reassign
The above comments describe a case where an editor using IStorageEditorInput is associated with multiple file extensions. Once created, the IStorageEditorInput has no means of determining what file extension was used to obtain the input. The IStorage#getFullPath() method is not adequate as the spec states that the path returned is at the discretion of the implementor (and can even be null). The possible solutions I see are: 1) Change the IStorage specification to say the file extension of the full path must be the file extension (breaking API change) 2) Add API to IStorageInput either through the abstract class or a sub- interface. 3) Change the IStorage spec to state that if the file extension of the full path is not the file extension then some editors will not work properly (and have those editors show the contents as text only or some other fallback). I don't see 1) happening so I'm moving this to Platform Text to get their opinion on 2). If that is not possible, we can do 3) for CVS but there may still be issues with other repository providers depending on how they implement the getFullPath method.
re 2) which abstract class do you mean: several clients directly implement IStorageEditorInput Michael, do you only want our comment on 2? Platform Text doesn't own it - it's Platform UI.
Moving to Platform UI in reponse to Dani's comment. Given that IStorageEditorInput can be implemented by clients, possibility 2 becomes: 2) Add a sub-interface to IStorageEditorInput to allow the implementor to be told which file extension was used to obtain the input.
we inherited this bug and have not looked at it, however I'm moving the target milestone
moving target to M4
M6 <sigh>
IStorage's spec can't be changed to refer to editors since IStorage is at core level. IEditorInput.getName() states: * Returns the name of this editor input for display purposes. * <p> * For instance, when the input is from a file, the return value would * ordinarily be just the file name. So while it specs only that the name is used for display purposes, it does suggest that the name can be treated as a file name when the input is a file. I was going to suggest: - editors show the input's name in the tab by default, but this can be overridden, so: - change RemoteFileEditorInput.getName() to exclude the revision number - add code to the editor to call setPartName(input.getName() + " " + input.getRevisionNumber()) However, the CVS repo explorer does not define its own editor. It uses the existing registered editors (how does it do the file to editor mapping?). So we need to provide the revision number in the tabs (which we don't want to lose) we need to keep the revision number in RemoteFileEditorInput.getName(). However, there's no requirement that IStorage.getName() return the same value. How about: - change your IStorage's getName() to return the regular file name - clients wanting to try mapping to a file name (and extension) for IStorageEditorInput use getName() on the IStorage rather than getName() on the editor input. There is still the problem about resolving the loose definition of IStorage.getName(), however this seems about the best we can do given the current APIs.
moving back to Core , please see comment #11
This means updating RemoteFileEditorInput.getFullPath() similarly, right?
Re comment 13: I believe that it already works the way Nick specified. That is, the getName() of the editor input includes the revision number since that is what is displayed in the tab but getName() of the IStorage obtained from the IStorageEditorInput does not include the revision name. The getFullPath() of the IStorage does include the revision at the end but that is for a different purpose (which unfortunately cannot be easily changed due to other clients). I'm going to mark this worksforme since you should be able to get the extension using IStorage#getName(). Please reopen if this is not the case.
