Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Platform just made a huge improvement to the IWorkspace.validateEdit facility in the M6 code stream...


As soon as the platform declares an I build with this fix, I will update our dependency and spin a build.

Do you want to open a WTP level bug to cover the porting effort to the new API in WTP?  Or is there one already?


John Lanuti
IBM Web Tools Platform Technical Lead, IBM Rational
IBM Software Lab - Research Triangle Park, NC
t/l 441-7861

"Konstantin Komissarchik" <kosta@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

03/01/2007 03:51 PM

Please respond to
"General discussion of project-wide or architectural issues."        <wtp-dev@xxxxxxxxxxx>

"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
[wtp-dev] Platform just made a huge improvement to the        IWorkspace.validateEdit facility in the M6 code stream...

... we should plan on picking up their next i-build as soon as possible because we will need time to go through our code and tweak all the places that we call validateEdit to take advantage of this. Here is a link to the platform bug that has just been resolved for those interested in the discussion and a quick summary of the problem.
Basically, platform provides an IWorkspace.validateEdit() method that should be called prior to modifying files in order to make sure that the team provider has a chance to take steps to make the file writable (contacting the source-control server, etc.). The validateEdit method takes a "context" parameter which is of type Object. The expectation up until now was that you either pass in an instance of the Shell or null depending on whether user prompting was acceptable. This works reasonably well for editors, but when file i/o is buried underneath layers of api, there is no way to get your hands on a Shell object. A lot of team providers are written to fail the validateEdit call when the Shell is not provided because they want to interract with the user. One team provider that behaves this way is the "default team provider" that takes care of making read-only files writable when no team provider has been configured for the project. It will fail with "file is read-only" excepion if the Shell is not provided. Not only is this a bad user experience (user expects to be prompted to make the file writable), but a lot of the calling code is not written to gracefully recover from such a failure. In any case, what the platform team has done to fix this issue is add a special flag that can be passed into the validateEdit method instead of a Shell object. Passing in this flag will cause platform internals to locate an appropriate Shell to give to the team provider. The new flag is IWorkspace.VALIDATE_PROMPT.
Ideally all the component teams should commit to find places in the WTP codebase that need to be modified to use the new prompt flag for 2.0. This can be done by either scanning the code (looking for calls to validateEdit as well as IFile.setContents) or by testing to see what areas need attention. An easy way to test for these problems is to create a project with some content and then make the entire project directory read-only (including all the . files and the contents of the .settings directory). The next step is to try manipulating the project. Everything that's accessible via project properties is suspect as file io in these contexts is definitely burried beneath api layers.
We (BEA's WTP team) will be doing our part (testing, opening bugs, and fixing issues) and we hope that other teams will step forward and help cover areas that we cannot cover.
I'm speaking at EclipseCon 2007

  Konstantin Komissarchik
Staff Software Engineer
Phone: 206.296.2962
IM: kosta0120 on Yahoo

BEA Systems, Inc.
999 North Northlake Way
Seattle, WA 98103
  Barring that natural _expression_ of villainy which we all have, the man looked honest enough.

                                                    Mark Twain              

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
wtp-dev mailing list

Back to the top