[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[platform-vcm-dev] First look: ValidateEdit/ValidateSave
|
ValidateEdit and validateSave support is now in! This is an initial cut;
there is refinement still to occur.
To get this support, you will need to take integration build 20011206 and
additionally load v214_VALIDATE_EDIT of org.eclipse.team.core in
dev.eclipse.org.
You will then need to implement two methods from ITeamProvider:
/*
* @see ITeamProvider#validateEdit(IFile[], Object)
*/
public IStatus validateEdit(IFile[] files, Object context) {
return new CVSStatus(IStatus.OK, "ok");
}
/*
* @see ITeamProvider#validateSave(IFile)
*/
public IStatus validateSave(IFile file) {
return new CVSStatus(IStatus.OK, "ok");
}
You of course will want to have a more interesting implementation :)
Some notes:
Our editors (vanilla, Java) now fire validateEdit. ValidateSave is fired
on resource setContents (as before) so its guaranteed.
The 'context' object for validateEdit is either null or an
org.eclipse.swt.widgets.shell which you can use for prompting.
We register for core's extension point and then call the appropriate
provider.
The separation between headless and 'headed' is weakened by us putting the
methods in ITeamProvider (i.e. due to implied dependency on SWT). However,
we felt this was the most straightforward solution for the moment and
seemed to match your requirements best. There is work to do here anyway
(reducing the need to implement everything in ITeamProvider if you don't
care about headless or reuse of UI).
The editor is the only one who fires validateEdit atm. As such, the array
will have a single IFile.
It is up to the provider to in turn make writeable files who were
successful checked out (IFile.setReadOnly(false)).
And, of course, you should consult the Java doc in Core.
There is more we'ld like to do around the area of user feedback of
read-only'ness, specifics of the contract between the editor and the
provider, etc., to make it play nicer.
Kevin