Hasta ahora, hemos dado por supuesto que se estaba utilizando la API de recursos para modificar los recursos situados en el sistema de archivos del usuario. Es cierto que esta es la estructura fundamental del área de trabajo, pero también existe la posibilidad de que un conector aporte prestaciones de manipulación de recursos gestionados en otra parte. Por ejemplo, los conectores de soporte de equipo de la plataforma aportan capacidad para trabajar con recursos sujetos a la gestión de un repositorio de versiones.
La API de recursos incluye prestaciones aportadas específicamente para permitir que los conectores de soporte de equipo y los conectores que implementan proveedores de repositorios utilicen el soporte del equipo. En este tema se describe el mecanismo genérico que permite registrar ganchos de recursos. En la sección Implementar un proveedor de repositorios hallará una descripción de cómo utiliza el equipo estos ganchos.
Este gancho permite que el conector de equipo y sus proveedores controlen cómo se implementan los movimientos y las supresiones de los recursos. El gancho incluye capacidad para impedir que tengan lugar estas operaciones. Los implementadores pueden proporcionar implementaciones alternativas para mover o suprimir archivos, carpetas y proyectos.
El conector del equipo utiliza el punto de extensión org.eclipse.core.resources.moveDeleteHook para registrar el correspondiente gancho:
<extension point="org.eclipse.core.resources.moveDeleteHook" id="MoveDeleteHook"> <moveDeleteHook class="org.eclipse.team.internal.core.MoveDeleteManager"/> </extension>
La clase suministrada debe implementar la interfaz IMoveDeleteHook, a la que llama la plataforma siempre que se mueve o suprime un recurso. El conector del equipo instala un gestor de ganchos de mover/suprimir que puede determinar qué proveedor del equipo está gestionando un recurso y luego invocar su gancho específico.
También existe la posibilidad de que los proveedores de repositorios de equipo tengan que impedir la edición o el guardado de un archivo o intervenir en estas operaciones. Para ello, el conector del equipo utiliza el punto de extensión org.eclipse.core.resources.fileModificationValidator con objeto de registrar un validador al que se llama siempre que se vaya a modificar un recurso.
<extension point="org.eclipse.core.resources.fileModificationValidator" id="FileValidator"> <fileModificationValidator class="org.eclipse.team.internal.core.FileModificationValidatorManager"/> </extension>
La clase suministrada debe implementar la interfaz IFileModificationValidator, a la que llama la plataforma siempre que se guarda o abre un recurso. El conector del equipo instala un gestor de modificación de archivos que puede determinar qué proveedor del equipo está gestionando un recurso y luego invocar su validador específico.
A veces, los proveedores de repositorio tienen que engancharse a operaciones adicionales de área de trabajo para imponer restricciones adicionales o personalizar el comportamiento del área de trabajo. El punto de extensión org.eclipse.core.resources.teamHook proporciona otras funciones especiales para los proveedores de equipo. En particular, este gancho permite que un proveedor de equipo decida si las carpetas y los archivos enlazados deben tener autorización para un proyecto determinado. Algunos sistemas de repositorio tienen reglas estrictas sobre el diseño físico de los proyectos en disco y no puede manejar recursos enlazados a ubicaciones arbitrarias.
El gancho de equipo también permite que un proveedor de repositorios proporcione una fábrica de reglas de planificación que utilizarán todas las operaciones de área de trabajo. Cada vez que se llame a un método API que modifique el área de trabajo de alguna manera, el área de trabajo obtendrá una regla de planificación. Esta regla d planificación impide que otras hebras modifiquen esos recursos durante la invocación del método API. Si un proveedor de repositorios realiza trabajo adicional en un validador de modificaciones de archivos o un gancho de mover/suprimir, el proveedor también debe indicar al área de trabajo cuáles son las reglas de planificación adicionales que necesitará. Consulte la sección sobre proceso por lotes de recursos para obtener más detalles sobre cómo el área de trabajo utiliza las reglas de planificación.
La clase proporcionada para el gancho de equipo debe implementar TeamHook. El conector del equipo instala un solo gancho de equipo que puede determinar qué proveedor del equipo está gestionando un recurso e invocar su gancho específico.
Nota: los tres ganchos de equipo se han diseñado específicamente para su uso por el conector central del equipo. No están destinados al uso general. Los proveedores de equipo no deben instalar ganchos mediante estos puntos de extensión, sino implementando sus ganchos en su clase Repository Provider. En el tema Ganchos de modificación de recursos del equipo hallará más información sobre la utilización de estos ganchos.