Esta sección describe los cambios que deben realizarse si intenta cambiar el conector 3.0 para adoptar los mecanismos y las API de 3.1.
Eclipse 3.1 proporciona una nueva infraestructura para definir operaciones que se pueden deshacer y un historial de operaciones compartido que hace un seguimiento de las operaciones que se han ejecutado, deshecho y rehecho. Las diversas infraestructuras de deshacer proporcionadas por conectores suplementarios deben migrarse cada cierto tiempo al soporte de operaciones de la plataforma, de manera que los clientes de estas infraestructuras puedan integrarse más profundamente con la plataforma y hacer que sus operaciones que no se pueden deshacer estén disponibles para deshacer en otras vistas y editores de conectores. Consulte la documentación de Operaciones que se pueden deshacer para obtener información sobre cómo añadir soporte de deshacer a un conector. Los conectores que ya definen soporte de deshacer o utilizan otra infraestructura pueden migrarse al nuevo soporte de deshacer de forma escalonada, como se describe a continuación.
Los conectores que ya definen clases que describen sus operaciones que se pueden deshacer deben añadir una implementación para la interfaz IUndoableOperation a sus clases de operaciones/mandatos. Los conectores todavía pueden utilizar infraestructuras más antiguas para gestionar el historial (pila de mandatos) si es necesario, pero proporcionar una interfaz para IUndoableOperation permite que los clientes del conector utilicen las mismas operaciones en el historial de operaciones de plataforma, y mezclar y comparar operaciones que no pueden deshacerse de distintos conectores. Esta estrategia es similar a la utilizada por los editores de texto SDK para migrar a la nueva infraestructura de operaciones. Si no es posible una correlación directa de la interfaz, los reiniciadores pueden utilizarse para correlacionar el protocolo IUndoableOperation con objetos de deshacer de legado. Esta estrategia la utiliza el soporte de refactorización de Plataforma/JDT. La migración de las clases de operación/mandato a IUndoableOperation es un paso importante, porque permite que las operaciones que no pueden deshacerse de distintas infraestructuras las utilicen otros conectores sin que ninguno de los conectores tengan que migrarse completamente.
Una vez que las operaciones o mandatos se expresan en términos de IUndoableOperation, los conectores que definen un historial que no se puede deshacer (pila de mandatos) para realizar un seguimiento de las operaciones que no se pueden deshacer y que no se pueden rehacer, pueden migrarse al historial de operaciones de plataforma definiendo un IUndoContext que representa su historial que no se puede deshacer. Los historiales de deshacer y que se gestionaron anteriormente de manera local, pueden fusionarse en el historial de operaciones común definiendo un contexto de deshacer exclusivo para cada componente o para cada objeto de modelo, añadiendo el contexto de deshacer adecuado para cada operación y, posteriormente, añadiendo la operación al historial de operaciones de la plataforma. Los historiales de deshacer con un ámbito más global pueden implementarse definiendo un contexto de deshacer exclusivo que represente ese ámbito de deshacer, asignando ese contexto a cada operación y, posteriormente, añadiendo la operación al historial de operaciones de la plataforma. Consulte la documentación de Operaciones que no se pueden deshacer para ver ejemplos para crear contextos de deshacer, asignarlos y añadir operaciones al historial de operaciones de la plataforma.
Los conectores que desean que sus operaciones se puedan deshacer desde las vistas del entorno de trabajo como, por ejemplo, Navegador o Explorador de paquetes, deben asignar el contexto de deshacer del entorno de trabajo a sus operaciones. Consulte la documentación de Operaciones que no se pueden deshacer para obtener más información sobre este contexto de deshacer y cómo pueden recuperarlo los conectores de entorno de trabajo y sin cabecera.
Los conectores que no definen una infraestructura de deshacer u operaciones que no se pueden deshacer, pero desea proporcionar acceso al historial de deshacer de la plataforma, deben estudiar el volver a dirigir los manejadores de acciones de deshacer y rehacer globales con los nuevos manejadores comunes de acciones de deshacer y rehacer. Se debe asignar a los manejadores de acciones un contexto de deshacer que especifique qué historial de deshacer o rehacer va a mostrarse. Los conectores pueden utilizar sus contextos de deshacer definidos localmente para mostrar el historial de deshacer y rehacer de "componente-local". El contexto de deshacer del entorno de trabajo puede utilizarse para mostrar el historial de deshacer y rehacer de todo el entorno de trabajo. De nuevo, la documentación de Operaciones que no se pueden deshacer tiene un ejemplo completo.
La migración de acciones de deshacer y rehacer del editor de texto es un poco diferente que la simple redirección de los manejadores de acciones globales de deshacer/rehacer. La infraestructura AbstractTextEditor define acciones de texto comunes utilizando un TextOperationAction parametrizado. Estas acciones se almacenan localmente en la infraestructura y se utilizan para enviar varios mandatos al destino de operación de texto de un editor. Para que la operación de deshacer texto funcione correctamente, la infraestructura del editor de texto se basa en la presencia de acciones de operaciones de texto con el ID adecuado (ITextEditorActionConstants.REDO e ITextEditorActionConstants.UNDO).
AbstractTextEditor se ha migrado para que cree los manejadores de acciones comunes, mientras sigue asignándolos a la tabla TextOperationAction con su ID de legado. De esta manera, los nuevos manejadores de acciones de deshacer y rehacer pueden recuperarse utilizando las técnicas de legado para recuperar la acción y realizar una operación. Los editores de texto de la jerarquía AbstractTextEditor heredarán este comportamiento.
Los editores que no hereden este comportamiento de AbstractTextEditor deben estudiar la migración de las acciones de deshacer y rehacer existentes para utilizar los nuevos manejadores. Los editores con TextOperationActions de deshacer y rehacer de legado seguirán teniendo soporte de deshacer local, dado que la API de gestor de deshacer de JFace Text utilizada por estas acciones sigue estando soportada. No obstante, las etiquetas de acciones de deshacer y rehacer no será coherente con las nuevas acciones de deshacer/rehacer SDK de Eclipse, que muestran el nombre de la operación de deshacer o rehacer disponible. Para crear los manejadores de acciones de deshacer y rehacer comunes, el contexto de deshacer utilizado por el gestor de deshacer del visor de texto debe emplearse al crear los manejadores de acciones, y esos manejadores deben establecerse en el editor utilizando el ID de ITextEditorActionConstants adecuado. Consulte AbstractTextEditor.createUndoRedoActions() y AbstractTextEditor.getUndoContext() para ver un ejemplo detallado. Los editores que se basan en una subclase EditorActionBarContributor para añadirse a las barras de acciones de sus editores pueden utilizar una técnica similar creando manejadores de acciones de deshacer y rehacer y estableciéndolos cuando se establece el editor activo.
Los conectores que contribuyen con páginas de búsqueda en el diálogo Buscar deben estudiar el portar todas las búsquedas de estilo de información en los motores de búsqueda federados. A partir de la versión 3.1, toda la búsqueda de estilo de información está separada de la búsqueda de artefactos del entorno de trabajo. Los motores de búsqueda de información se ejecutan en paralelo como trabajos de segundo plano y sus resultados se clasifican en la nueva vista de ayuda. Consulte Búsqueda de ayuda para obtener más detalles.
La nueva vista de ayuda dinámica trabajará con los ID de contexto existente
que están asociados estáticamente con widgets en componentes y diálogos del
entorno de trabajo.
Sin embargo, si capta el evento de ayuda el propio usuario y muestra la ayuda,
la vista de ayuda dinámica no podrá mostrar nada útil.
Para arreglar el problema, debe adaptarse a la nueva interfaz
IContextProvider
como se describe en el documento
Ayuda de contexto dinámica.