Community
Participate
Working Groups
I am a pessimistic team provider trying to determine if a validateEdit() is called as part of a refactoring process. Here is the scenario: 1) validateEdit() gives me the list of files involved, where validateSave() gives only one file at a time - I want to check out all files together (increased performance). 2) Not all users are allowed to rename files, so the IMoveDeleteHook moveFile() might not be allowed. In this case, I don't want to check out a bunch of files in validateEdit(). Solution: There should be a way to determine if I am in a refactor operation from validateEdit(). A kluge in Eclipse 2.1 was to check the shellContext parameter of the validateEdit(). If it was null, then it was in a refactor process. If it was non-null, then the validateSave() was called from an editor.
*** Bug 127721 has been marked as a duplicate of this bug. ***
Why does the origin of the validateEdit request matter. The intent is that if a client wants to edit the contents of one or more files they call validateEdit with all files and a Shell. The provider would then take whatever measures were necessary to checkout the files and eitehr return success or failure. Validate save was a callback that was there to handle the case where clients don't call validateEdit ahead of time (i.e. it is only a safeguard). What you are describing sounds like it is outside the context of what validateEdit was intended for. That is, it sounds like there is some policy in place that says that valdiateEdits shoudl succeed as part of a refactoring but not when files are edited. One thing you mention that does overlap with validateEdit is the inclusion of moves. I think what you are asking for here is a complete description of the change so that you can perform validation with the complete knowledge of all changes. We have added API in 3.2 that support this type of validation for modle providers but does not allow repository providers to validate the change. Unfortunately, our API is now frozen for 3.2 so this will have to wait until the next release.
(In reply to comment #2) > Why does the origin of the validateEdit request matter. The intent is that if a > client wants to edit the contents of one or more files they call validateEdit > with all files and a Shell. The provider would then take whatever measures were > necessary to checkout the files and eitehr return success or failure. Validate > save was a callback that was there to handle the case where clients don't call > validateEdit ahead of time (i.e. it is only a safeguard). > > What you are describing sounds like it is outside the context of what > validateEdit was intended for. That is, it sounds like there is some policy in > place that says that valdiateEdits shoudl succeed as part of a refactoring but > not when files are edited. > > One thing you mention that does overlap with validateEdit is the inclusion of > moves. I think what you are asking for here is a complete description of the > change so that you can perform validation with the complete knowledge of all > changes. We have added API in 3.2 that support this type of validation for > modle providers but does not allow repository providers to validate the change. > Unfortunately, our API is now frozen for 3.2 so this will have to wait until > the next release. > There are two problems with the implementation of FileModificationValidator: 1) If a team provider checks out all the files here, and the is the first step of a refactor operation, if refactor fails for any reason all files will remain checked out since the team provider won't be able to correct this situation. In my case, one situation that will prevent the "Rename" and thus a refactor would fail is if the user does not have authority to "Rename" a file. Since I don't know in validateEdit() that it is part of a larger operation, I will check out all the files even though the user can't continue the refactor. The result is all files checked out, but the refactor does not go through. This could happen for other reasons as well, such as the files involved being modified by external editors, etc. 2) validateEdit() is called at the beginning of file modifications and validateSave() is called just before saving the changes. As a team provider I want a validateSaved() or validateFinished() that will tell me that all files of this operation are finished being modified. This would allow me to check the files in, if I so decide.
1) Yes, this is a problem. What this would require is some sort of unedit that clients call if they fial to change files after calling validateEdit 2) This is not the intent of validateSave so I wouldn't use it that way. The problem is that you cannot assume that all Eclipse tools that use your repository provider will have refactoring operations. In the absense of refactoring, a user would need to manually check-out all the files they need, then perform a bunch of edits and then check-in their changes (using a menu action you provide). To put it another way, I may be performing a complex change that requires several refactorings and I don't want to check-in my changes until all the refactorings are done. For this reason, we keep the check-in lifecycle separate from validateEdit.
1) The problem with the idea of unedit is that you have already incurred the overhead to check out all affected files from validateEdit(), then you must undo all those check outs. This is highly inefficient for a client/server configuration where a check out might take some time. Knowing what kind of operation you are in during validateEdit() would prevent a large check out, and then a subsequent undo check out. 2) I agree that validateSave() should not be used this way, but there should be a separate (new) method that indicates that file modifications are complete. This seems most appropriate for IFileModificationValidator interface. If there were a new method, such as validateFinished() or some other name, that was called upon completion of all modifications it would be very useful. As it stands, there appears to be no other way.
Sorry but I still don't see how a validateFinished helps. Also, I don't know how clients would know when the user is finished. Clients would know when a particular atomic operation was completed but would never be able to say when the complete logical operation was completed. What are you are trying to accomplish with a validateFinish? Is it just that you want to undue any checkouts if the operation failed? It sounds like, from your first paragraph, that a validateEdit that accepted a pre-delta description of the complete change would allow you to accept or reject the change in it's entirety (i.e. you would see both the file edits and the move and be able to accept/reject if the user has the ability to move files).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
