Modifiche necessarie quando si adottano i meccanismi e le API 3.1

Questa sezione descrive le modifiche necessarie se si tenta di sostituire il plugin 3.0 per adottare i meccanismi e le API 3.1.

Supporto annullamento/ripetizione operazioni della piattaforma

Eclipse 3.1 fornisce una nuova infrastruttura per la definizione delle operazioni annullabili e una cronologia operazioni condivisa che tiene traccia delle operazioni eseguite, annullate e ripetute. I diversi framework di annullamento operazioni forniti da plugin aggiuntivi dovrebbero essere migrati nel tempo al supporto delle operazioni di piattaforma, in modo che i client di questi framework possano integrarsi meglio con la piattaforma e rendere le operazioni annullabili disponibili per l'annullamento in altre viste ed editor di plugin. Per informazioni di base sull'aggiunta del supporto di annullamento ad un plugin, fare riferimento alla documentazione sulle Operazioni annullabili. I plugin che dispongono di un supporto di annullamento già definito o che utilizzano un'altro framework possono essere migrati al nuovo supporto di annullamento operazioni in modalità per fasi, come illustrato di seguito.

Migrazione di classi di operazioni (comandi) specifiche di plugin in IUndoableOperation

I plugin che definiscono già classi che descrivono le proprie operazioni annullabili, devono aggiungere un'implementazione all'interfaccia IUndoableOperation per le proprie classi di operazioni/comandi. I plugin possono ancora utilizzare i vecchi framework per gestire la cronologia (stack di comandi) se necessario, tuttavia fornendo un'interfaccia per IUndoableOperation si consente ai client di plugin di utilizzare le stesse operazioni nelle cronologia operazioni della piattaforma, e di combinare le operazioni annullabili di diversi plugin. Questa strategia è simile a quella utilizzata dagli editor di testo SDK per migrare al nuovo framework delle operazioni. Se non è possibile un'associazione diretta dell'interfaccia, possono essere utilizzati i wrapper per associare il protocollo IUndoableOperation agli oggetti di annullamento precedenti. Questa strategia viene utilizzata dal supporto di refactoring della piattaforma/JDT. La migrazione delle classi di operazioni/comandi a IUndoableOperation è una fase importante in quanto consente alle operazioni annullabili di diversi framework di essere utilizzate da altri plugin senza che i plugin debbano migrare completamente.

Migrazione degli stack di comandi con IOperationHistory

Una volta che le operazioni o i comandi annullabili sono espressi in termini di IUndoableOperation, i plugin che definiscono una cronologia annullamento (stack di comandi) per mantenere traccia delle operazioni annullabili e ripetibili possono migrare alla cronologia operazioni della piattaforma, definendo un IUndoContext che rappresenta la propria cronologia di annullamento. Le cronologie di annullamento che erano precedentemente gestite in locale, possono essere unite nella cronologia operazioni comune definendo un unico contesto di annullamento per tutte le parti e gli oggetti del modello, aggiungendo il contesto di annullamento appropriato a ciascuna operazione e poi aggiungendo l'operazione alla cronologia operazioni della piattaforma. Le cronologie di annullamento con più ambiti globali possono essere implementate definendo un unico contesto di annullamento che rappresenta l'ambito di annullamento, assegnando tale contesto a ciascuna operazione e poi aggiungendo l'operazione alla cronologia operazioni della piattaforma. Per esempi della creazione dei contesti di annullamento, la loro assegnazione e l'aggiunta di operazioni alla cronologia operazioni della piattaforma, fare riferimento alla documentazione sulle Operazioni annullabili.

Definizione di operazioni annullabili globali per il workbench

I plugin che vogliono rendere le proprie operazioni annullabili dalle viste del workbench, quali Selezione o Esplora pacchetti, devono assegnare il contesto di annullamento del workbench alle proprie operazioni. Per ulteriori informazioni su questo contesto di annullamento e sulle modalità di richiamo da parte del workbench e dei plugin headless, fare riferimento alla documentazione sulle Operazioni annullabili.

Gestori delle azioni di annullamento/ripetizione operazioni della piattaforma

I plugin che non definiscono un'infrastruttura di annullamento o operazioni annullabili, ma che vogliono fornire accessi alla cronologia di annullamento operazioni della piattaforma, devono valutare la riassegnazione dei gestori delle azioni di annullamento/ripetizione globali con nuovi gestori comuni. Ai gestori delle azioni deve essere assegnato un contesto di annullamento che specifichi quale cronologia di annullamento/ripetizione visualizzare. I plugin possono utilizzare i propri contesti di annullamento definiti in locale per mostrare la cronologia di annullamento/ripetizione "a livello locale". Il contesto di annullamento del workbench può essere utilizzato per mostrare la cronologia di annullamento/ripetizione "a livello workbench". Per un esempio completo, fare riferimento alla documentazione sulle Operazioni annullabili.

Migrazione di azioni sul testo ai gestori di azioni comuni

La migrazione delle azioni di annullamento/ripetizione dell'editor di testo è leggermente diversa da una semplice riassegnazione ai gestori delle azioni di annullamento/ripetizione globali. Il framework AbstractTextEditor definisce le azioni sul testo comuni utilizzando un TextOperationAction parametrizzato. Queste azioni sono archiviate in locale nel framework ed utilizzate per inviare i diversi comandi ad una destinazione dell'operazione sul testo dell'editor. Affinché l'annullamento delle operazioni sul testo avvenga correttamente, il framework dell'editor di testo si basa sulla presenza di azioni sul testo con gli id appropriati (ITextEditorActionConstants.REDO e ITextEditorActionConstants.UNDO).

AbstractTextEditor è stato migrato in modo da creare i gestori di azioni comuni, anche se li assegna ancora alla tabella TextOperationAction con i relativi id. In questo modo, i nuovi gestori delle azioni di annullamento/ripetizione possono essere richiamati utilizzando le tecniche proprietarie per richiamare l'azione ed eseguire un'operazione. Gli editor di testo nella gerarchia AbstractTextEditor erediteranno questo comportamento.

Gli editor che non ereditano questo comportamento da AbstractTextEditor devono valutare la migrazione di tutte le azioni di annullamento/ripetizione esistenti per utilizzare i nuovi gestori. Gli editor con TextOperationAction di annullamento/ripetizione proprietarie disporranno ancora del supporto di annullamento locale, dal momento che l'API di gestione degli annullamenti di testo JFace utilizzata da queste azioni è ancora supportata. Tuttavia, le etichette delle azioni di annullamento/ripetizione non saranno congruenti con le nuove azioni di annullamento/ripetizione di Eclipse SDK, che mostrano il nome dell'operazione di annullamento/ripetizione disponibile. Per creare i gestori delle azioni di annullamento/ripetizione comuni, il contesto di annullamento del gestore annullamenti del visualizzatore di testo deve essere utilizzato quando si creano i gestori della azioni, e tali gestori devono essere impostati nell'editor utilizzando l'id ITextEditorActionConstants appropriato. Per un esempio dettagliato, fare riferimento a AbstractTextEditor.createUndoRedoActions() e AbstractTextEditor.getUndoContext(). Gli editor che si basano su una sottoclasse EditorActionBarContributor per aggiungere le barre di azione degli editor possono utilizzare una tecnica simile creando i gestori delle azioni di annullamento/ripetizione ed impostandoli quando viene impostato l'editor attivo.

Miglioramenti alla guida

Ricerca di informazioni

I plugin che contribuiscono alle pagine di ricerca nella finestra di dialogo Ricerca devono valutare il trasferimento delle ricerche di informazioni ai motori di ricerca federati. Dalla versione 3.1, tutte le ricerche di informazioni sono separate dalla ricerca di risorse del workbench. I motori di ricerca delle informazioni sono eseguiti in parallelo, come lavori in background, e i risultati sono riuniti nella nuova vista della Guida. Per ulteriori dettagli, fare riferimento a Ricerca argomenti.

Guida dinamica

La nuova vista della guida dinamica opererà con gli ID di contesto esistenti che sono associati in modo statico ai widget nelle parti e nei dialoghi del workbench. Tuttavia, se l'utente intercetta gli eventi della guida e la visualizza, la guida dinamica non sarà in grado di visualizzare informazioni utili. Per risolvere il problema, è necessario adattarsi alla nuova interfaccia IContextProvider, come descritto nel documento Guida sensibile al contesto dinamica.