[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[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.
_______________________________________________________________________
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.