Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [platform-vcm-dev] Team + Refactoring (cont.) 
The first part of Kevin's explanation made sense to me,
i.e. ValidateEdit is only for content changes, and therefore
is not called on rename/move/delete, but is called if the
rename/move resulted in a content change, at which time
ValidateEdit should be invoked.  (I.e. if ValidateEdit is
being called on rename/move/delete, it should be called
on the folders involved, but not calling it at all on rename/
move/delete is fine).

The second part of the explanation did raise a question ...
the move/rename/delete hook certainly is the right place to
handle move/rename/delete processing.  But why is "delta notification"
relevant here, since delta's are about content, and 
rename/move/delete are namespace operations, not content
operations?

Cheers,
Geoff



-----Original Message-----
From: Kevin McGuire [mailto:Kevin_McGuire@xxxxxxx]
Sent: Friday, June 21, 2002 3:12 PM
To: platform-vcm-dev@xxxxxxxxxxx
Subject: RE: [platform-vcm-dev] Team + Refactoring (cont.)



No, this isn't a bug:

ValidateEdit() is unrelated to namespace operations.  Its only called when
content changes are about to occur.  I believe what's happening in the case
cited is that when you rename a Java file, Java refactoring kicks in and
renames the class declaration to match the filename.  Thus you are getting
the validateEdit() notification from the Java refactoring engine who is
being a good citizen.  The context is null presumably because they don't
have access to the shell at the point in their code where they need to call
validateEdit().

You can't rely on validateEdit() for rename/move/delete -- if you do the
same steps with a non-java file you won't get notified via this.  You can
find out about move/rename/delete either via delta notification, or via the
move/rename/delete hook in the provider (depending on whether you require
veto or extra work to occur).

If this doesn't match what you are seeing let me know.

Cheers,
Kevin





 

                      "Clemm, Geoff"

                      <gclemm@xxxxxxxxxxxx>           To:
platform-vcm-dev@xxxxxxxxxxx                         
                      Sent by:                        cc:

                      platform-vcm-dev-admin@         Subject: RE:
[platform-vcm-dev] Team + Refactoring (cont.)    
                      eclipse.org

 

 

                      06/20/2002 11:29 PM

                      Please respond to

                      platform-vcm-dev

 

 




This is a significant bug.  A move/rename is not a modification
to the file being moved, it is a modification to the directory/folder
that originally contained the file, and a modification to the
directory/folder that will contain the file.

So MOVE(/a/b, /c/d) should result in an IFileModification to
/a and an IFileModification to /b, not to /a/b or to /c/d.

Similarly, a DELETE(/a/b) should result in an IFileModification
to /a, not to /a/b.

On the other hand, a COPY(/a/b, /c/d) should result in an
IFileModification to /c/d.

Cheers,
Geoff

-----Original Message-----
From: David Corbin [mailto:dcorbin@xxxxxxxx]
Sent: Thursday, June 20, 2002 6:44 PM
To: platform-vcm-dev@xxxxxxxxxxx
Subject: [platform-vcm-dev] Team + Refactoring (cont.)


When a Java file is renamed, I'm getting a call to
IFileModification.validateEdit with a null context.  This is problematic
for us.  We really need to know that it is being moved before it is
being edited.

I'm not (personally) familiary with IFileModification, but is there any
way for us get the move first before the edit attempt, or for the
validateEdit to provide context that tells us this is being called as
apart of a rename/move?

Back to the top