Esta secção descreve as alterações que são necessárias se for tentar alterar o plug-in 3.0 para adoptar os mecanismos e as APIs do 3.1.
O Eclipse 3.1 faculta uma nova infra-estrutura para definir operações anuláveis e um histórico de operações partilhado que mantém um rastreio das operações que foram executadas, anuladas e refeitas. As várias estruturas de anulação facultadas pelos plug-ins add-on devem migrar com o tempo para o suporte de operação da plataforma, para que os clientes destas estruturas possam migrar de forma mais profunda na plataforma e disponibilizar as suas operações anuláveis para anular noutras vistas e editores do plug-in. Consulte a documentação sobre Operações anuláveis para obter informação básica sobre a adição de suporte de anulação num plug-in. Os plug-ins que já definem o suporte de anulação ou utilizam outra estrutura podem ser migrados para o novo suporte de anulação de forma faseada, como se descreve a seguir.
Os plug-ins que já definem classes que descrevem as suas operações anuláveis devem adicionar uma implementação da interface IUndoableOperation às respectivas classes de operação/comando. Os plug-ins podem ainda utilizar estruturas antigas para gerir o histórico (pilha de comandos) caso seja necessário, mas facultar uma interface para IUndoableOperation vai permitir que os clientes de um plug-in utilizem as mesmas operações no histórico das operações da plataforma e misturar e corresponder operações anuláveis de diferentes plug-ins. Esta estratégia é semelhante à utilizada pelos editores de texto de SDK para migrar para a nova estrutura de operações. Se não foi possível uma correlação directa da interface, os translineadores podem ser utilizados para correlacionar o protocolo IUndoableOperation para objectos de anulação legacy. Esta estratégia é utilizada pelo suporte de refactorização Plataforma/JDT. A migração das classes de operação/comando para IUndoableOperation é um passo importante porque permite que as operações anuláveis de diferentes estruturas sejam utilizadas por outros plug-ins sem que o plug-in tenha de migrar completamente.
Uma vez que as operações ou comandos anuláveis sejam expressas em termos de IUndoableOperation, os plug-ins que definem um histórico de anulação (pilha de comandos) para manter um rastreio das operações de anular e refazer, podem migrar para o histórico das operações da plataforma definindo um IUndoContext que represente o respectivo histórico de anulação. Os históricos de anulação que já tenham sido geridos localmente podem ser intercalados para o histórico de operações comum, definindo um contexto de anulação único, quer seja para cada parte quer seja para cada objecto de modelo, adicionando o contexto de anulação apropriado a cada operação e depois adicionando a operação ao histórico de operações da plataforma. Os históricos de anulação com mais âmbito global podem ser implementados definindo um contexto de anulação único, representando esse âmbito de anulação, atribuindo esse contexto a cada operação e depois adicionando a operação ao histórico de operações da plataforma. Consulte a documentação sobre Operações anuláveis para obter exemplos da criação de contextos de anulação, sua atribuição e adição de operações ao histórico de operações da plataforma.
Os plug-ins que quiserem que as operações sejam anuláveis das vistas da área de trabalho, como o Navegador ou o Explorador de Pacotes, devem atribuir o contexto de anulação da área de trabalho às respectivas operações. Consulte a documentação sobreOperações anuláveis para obter mais informações sobre este contexto de anulação e como pode ser obtido pelos plug-ins da área de trabalho e sem cabeçalho.
Os plug-ins que não definam uma infra-estrutura de anulação ou operações anuláveis, mas que pretendam facultar acesso ao histórico de anulação da plataforma, devem considerar voltar a enfatizar as rotinas de tratamento da acção anular e refazer global com as novas rotinas de tratamento da acção anular e refazer comuns. Às rotinas de tratamento da acção deve ser atribuído um contexto de anulação a especificar o histórico de anular e refazer que será apresentado. Os plug-ins podem utilizar os contextos de anulação definidos localmente para mostrar o histórico de anular e refazer "part-local". O contexto de anulação da área de trabalho pode ser utilizado para mostrar o histórico de anular e refazer em toda a área de trabalho. De novo, a documentação sobre Operações anuláveis tem um exemplo completo.
A migração das acções anular e refazer do editor de texto é um pouco diferente de apenas voltar a enfatizar as rotinas de tratamento de acções anular/refazer globais. A estrutura AbstractTextEditor define acções de texto comuns que utilizam uma TextOperationAction parametrizada. Estas acções são armazenadas localmente na estrutura e são utilizadas para enviar vários comandos para um destino de operação de texto do editor. Para que a anulação de texto funcione correctamente, a estrutura do editor de texto depende da presença das acções da operação de texto com os ids adequados (ITextEditorActionConstants.REDO e ITextEditorActionConstants.UNDO).
AbstractTextEditor foi migrado para criar as rotinas de tratamento de acções comuns, enquanto ainda as atribui à tabela TextOperationAction com os ids de legacy. Desta forma, as novas rotinas de tratamento de acções anular e refazer podem ser obtidos utilizando as técnicas legacy para obter a acção e executar uma operação. Os editores de texto na hierarquia AbstractTextEditor vão herdar este comportamento.
Os editores que não herdarem este comportamento do AbstractTextEditor devem considerar a migração de acções anular e refazer existentes com a utilização das novas rotinas de tratamento. Os editores com anular e refazer legacy TextOperationActions ainda têm suporte de anulação local a funcionar, uma vez que a API do gestor de anulação do Texto de JFace utilizada por estas acções ainda é suportada. Contudo, as etiquetas da acção anular e refazer não será consistente com as novas acções anular/refazer do Eclipse SDK, que mostram o nome da operação de anular e refazer disponível. Para criar as rotinas de tratamento da acção anular e refazer comuns, o contexto de anulação utilizado pelo gestor de anulação do visualizador de texto deve ser utilizado ao criar as rotinas de tratamento da acção e essas rotinas de tratamento devem ser definidas para o editor que utilizar o id adequado de ITextEditorActionConstants. Consulte AbstractTextEditor.createUndoRedoActions() e AbstractTextEditor.getUndoContext() para obter um exemplo detalhado. Os editores que dependem que uma subclasse EditorActionBarContributor seja adicionada às barras de acções dos editores podem utilizar uma técnica semelhante, criando as rotinas de tratamento da acção anular e refazer e definindo-as quando estiver definido o editor activo.
Os plug-ins que contribuem páginas de pesquisa para a caixa de diálogo Pesquisar devem considerar a aportagem de todas as pesquisas de estilo informativo em motores de pesquisa federados. Desde o 3.1, toda a pesquisa de estilo informativo é separada da pesquisa de artefactos da área de trabalho. Os motores de pesquisa de informações são executados em paralelo com os trabalhos de segundo plano e os respectivos resultados comparados na nova vista Ajuda. Consulte Pesquisa de Ajuda para obter mais detalhes.
A nova vista ajuda dinâmica vai funcionar com IDs de contexto existentes que
estejam associados de forma estática a widgets nas partes e caixas de diálogo da área de
trabalho. Contudo, se capturar você mesmo um evento de ajuda e mostrar a ajuda, a vista ajuda dinâmica não conseguirá apresentar nada que seja útil.
Para corrigir este problema, deve adaptar-se à nova interface
IContextProvider
, tal como está descrito no documento Ajuda de Contexto Dinâmica.
A partir da edição 3.1, o org.eclipse.jface.preference.IPreferenceStore devolvido a partir do AbstractUIPlugin.getPreferenceStore() será uma instância de org.eclipse.ui.preferences.ScopedPreferenceStore. O ScopedPreferenceStore utiliza a API org.eclipse.core.runtime.preferences para gerir as preferências. Na edição 3.0 utilizava-se o nível de compatibilidade para a interface com uma instância org.eclipse.core.runtime.Preferences.
Na edição 3.1 eliminou-se a ambiguidade do IPreferenceStore para que se torne mais específico sobre o tipo de valores enviados em eventos alterados de preferências. O IPreferenceStore de AbstractUIPlugin#getPreferenceStore tem o mesmo comportamento que tinha anteriormente. Contudo, é agora especificado de forma mais clara.
Typing: org.eclipse.jface.util.IPropertyChangeListener
adicionado a um IPreferenceStore pode obter, potencialmente, dois tipos de valores antigos e novos, representações escritas ou de cadeia. Qualquer evento gerado por uma chamada para uma API IPreferenceStore escrita (como setValue (chave de cadeia, valor booleano)
irá gerar um evento escrito.
Contudo, é também possível que os eventos sejam propagados a partir das
preferências de núcleo em tempo de execução que geram um evento sem tipo (como
por exemplo, numa importação de preferência). Os auditores de propriedades têm de estar preparados para ambos. Repare que todos os eventos escritos não irão colocar tipos principais, por isso, uma chamada para setValue(String key, boolean value)
irá resultar num evento onde oldValue e newValue são valores booleanos.
putValue: IPreferenceStore.putValue (chave de cadeia, valor de cadeia) irá gerar um evento de alteração. Esta API destina-se a ser utilizada para preferências privadas às quais nenhum auditor pretende reagir.
initializeDefaultPreferences. Esta API foi eliminada no Eclipse 3.0, já que é apenas disparada se o nível de compatibilidade for utilizado. Como a maioria dos plug-ins se baseia em AbstractUIPlugin#getPreferenceStore para obter o respectivo armazenamento de preferências, este estava a ser disparado anteriormente no arranque do plug-in. Se o plug-in não aceder ao nível de compatibilidade por si só, então este método poderá não ser disparado. Recomenda-se que crie um org.eclipse.core.runtime.preferences.AbstractPreferenceInitializer para processar a inicialização de preferências.