Community
Participate
Working Groups
This bug came out of the discussion in bug #28123. There have been recent cases where the validateEdit spec needs improvement. These are: 1. The validateEdit spec is unclear whether given a UI context the receiver *must* prompt to inform the user of the reason why the file can't be modified. It reads, "By passing a UI context, the caller indicates that the VCM component may contact the user..." The word "may" suggests its not required. However, if the caller provides a UI context, they reasonably assume that they don't need to prompt. The word should be "must". Currently the default provider never prompts, which according the spec seems ok, but is a problem in practice. What must be avoided is the situation where the user is informed twice that the file is read-only (once by the caller, once by the provider). 2. Just because the caller provided a UI context it doesn't mean that the provider is able to prompt. This can happen if the provider is headless. Forcing the provider to prompt means that it will require dependence on UI code which it might not otherwise have (case in point, the no-provider case handled by VCM). 3. The caller would like to know if its ok to offer to the user to make the file writeable. This can happen if there is no provider (ie. the file just happens to be read-only), or if there is a provider but it doesn't care about the file (e.g. the file isn't under version control, the provider is CVS and not enforcing CVS EDIT). 3. It has been suggested that it would be handy for callers if they could always call validEdit regardless of whether file was read-only or not. This is easy to achieve on the part of the VCM code -- we could filter out all resources which are read-only before forwarding them off to the provider. This change can be made in a backwards compatible, non-API breaking way. However, there is a slight performance hit, since checking read-only is expensive, we will be in a position where both the caller and VCM (and likely the provider too) are all checking the read-only status of the same file. ------ Discussion ------ #1, #2: A possible solution would be the use of a return code in the status to signal to the caller that prompting didn't occur. This allows for the case where the provider couldn't prompt. It also allows the spec to be more specific, requiring that given a UI context, the provider must either prompt, or set the return code saying they couldn't prompt. #3: According to the spec, if the file is still read-only after the validateEdit call, an ERROR status should be returned. The code in VCM to handle no- provider implements this case, and returns an ERROR status for all read-only files, with the message "The file is read-only". This is a bit redundant though: the caller has asked if its ok to write to a read-only file, and he gets back "No, its read-only". We need to distinguish two cases: 1. The provider attempted to check-out the file but failed. 2. There is no provider, or the file isn't under version control. In the second case, the provider/VCM has no opinion on whether the file should be made writeable or not. It would be nice if there was a way for it to signal this to the caller. Since the spec creates a 1:1 correspondance between the file being read-only after the call, and getting an error status, the read-only state on return is redundant. So for the second case, we could return "OK", but leave the file read-only, which would indicate that the file can be made writeable by the caller. Or, would could use a return code to indicate that as far as the provider is concerned, the file can be made writeable by the caller. The file would still come back read-only with Error return status, so I think I prefer the first solution for simplicity. However, its not clear we can do the first method without breaking the spec. The second, the use of the a return code, wouldn't break the spec: those who don't check it are left as they are right now with a read-only file, those who do can perform additional work to inform the user that the file can be made writeable if they so choose. Note that #1 and #3 are related: in the no-provider case where the caller would like to ask the user if they want to make the file writeable, it would be good if it was the caller who prompted to inform that the file was read- only, since they can do it in the same prompt. They would know they can combine the prompt because they would get back "Didn't prompt" from the default provider code in VCM.
Spec clarification #4: When passing in multiple files one or more files could be rejected for check- out. The remaining files should still be processed by the caller. There needs to be a way to determine which files were rejected. Currently the spec suggests either all files are ok or none. In this scenario I rely on the fact that I get a multi status with one status for each file that I passed in. The status children must be in the order of the passed files. This should be clarified in the spec.
Re Knut's comment #1 >>The remaining files should still be processed by the caller. There needs >>to be a way to determine which files were rejected. >>Currently the spec suggests either all files are ok or none. Its not clear you should attempt the operation on those which succeeded validation. Partial failure means the user isn't able to check out all the files or parent directories required to do the operation. In this case, they really can't do the work because they know they won't be able to check it back in. This generally is a big deal, and they must do things like find out who has the items checked out and convince them to check them back in. This same case also occurs for JDT operations such as refactoring, where its better to just re-attempt the refactoring once the locked files have been made available. So its actually easier for the user to just retry the operation once the roadblock's been removed, instead of having to deal with the mess of a partially failed operation. This is the usage culture, as I understand it.
When I pass multiple files to validateEdit in the pessimistic provider scenario I get prompted which files I want to check out. validateEdit returns ok for those that I left checked. In this scenario it does not make sense to abort the operation because the user explicitly unchecked some files. Unless of course the example is bogus (or fabricated to allow the tester to make some of the files fail "check-out"?). I don't know if this type of user prompt is consistent with real world scenarios or if VCM providers would always attempt to check-out all files.
I assume its there for testing. Since in practice the user isn't allowed to change the resources if they aren't checked out, I don't see why the provider would prompt. I've asked Peter Hack to comment on "real world usage" though.
This bug report should now be closed. The following are the resolutions: >>#1: The validateEdit spec is unclear whether given a UI context the receiver *must* prompt The spec should probably be reworded to "must prompt", so that the caller can assume that they don't have to and to avoid double prompting. In practice I believe this is what everyone does anyway. I have entered a separate bug report for it (bug #30549). >>#2. Just because the caller provided a UI context it doesn't mean that the provider is able to prompt. The default provider will be changed to prompt (its bug report has been updated). >>#3. The caller would like to know if its ok to offer to the user to make the file writeable. No work planned. Offering to make the file writeable is of questionable value and only applies for read-only files where there is no provider, which is odd. While the default provider could do this (since it will now prompt), we believe at this time that we don't want to offer this option to the user: its not clear why a file in Eclipse would be read-only and changing this is probably too helpful for the user's good. Since the user can make the files writeable himself, there is a reasonable (and safer) workaround. #4 (listed as 3 by accident). It has been suggested that it would be handy for callers if they could always call validEdit regardless of whether file was read-only or not I've created a separate bug report for it, bug #30550
Closing.
