Nota do Editor: Uma versão atualizada deste artigo, intitulada " Criar um Aplicativo Baseado no Eclipse Usando Graphical Editing Framework" foi publicada em março de 2007. Esta versão original permanecerá disponível para propósito de referência. Leia o novo artigo para entender os recursos mais recentes em GEF.

O artigo o guia pelas etapas de uso de GEF. Em vez de concluir cada etapa completamente, usaremos um subconjunto do modelo de seu aplicativo e deixaremos isso funcional primeiro. Por exemplo, podemos ignorar inicialmente as conexões ou focar apenas um subconjunto dos tipos de elementos gráficos em seu aplicativo.

Visão Geral de GEF

GEF supõe que você possui um modelo que você gostaria de exibir e editar graficamente. Para fazer isso, GEF fornece visualizadores (do tipo EditPartViewer) que podem ser usados em qualquer parte do ambiente de trabalho Eclipse. Como os visualizadores JFace, os visualizadores GEF são adaptadores em um SWT Control. Mas a semelhança para aí. Os visualizadores GEF são baseados na arquitetura Model-View-Controller (MVC).

Os controladores fazem a ponte entre a visualização e o modelo (consulte a Figura 1). Cada controlador, ou EditPart como são chamados aqui, é responsável por mapear o modelo para sua visualização e por fazer mudanças no modelo. EditPart também observa o modelo e atualiza a visualização para refletir as mudanças no estado do modelo. EditParts são os objetos com os quais o usuário interage. EditParts são tratados em mais detalhes posteriormente.

GEF fornece dois tipos de visualizadores: gráfico e baseado em árvore. Cada um hospeda um tipo diferente de visualização. O visualizador gráfico usa figuras que são exibidas, no SWT, em uma Tela. As figuras são definidas no plug-in Draw2D, que é fornecido como parte de GEF. O TreeViewer usa Tree e TreeItems do SWT para sua visualização.

Voltar para parte superior

Etapa 1. Trazer seu Próprio Modelo

GEF não conhece nada sobre um modelo. Qualquer tipo de modelo deve funcionar, desde que atenda as propriedades descritas abaixo.

O que Está no Modelo?

Tudo está no modelo. O modelo é a única coisa persistida e restaurada. Seu aplicativo deve armazenar todos os dados importantes no modelo. Durante o andamento de editar, desfazer e refazer, o modelo é a única coisa que perdura. Figuras e EditParts serão lixo coletado e recriados ao longo do tempo.

Quando o usuário interage com EditParts, o modelo não é manipulado diretamente por EditParts. Em vez disso, um Comando é criado que encapsula a mudança. Comandos podem ser usados para validar a interação do usuário e fornecer suporte para desfazer e refazer.

Falando de forma rígida, os Comandos também são, conceitualmente, parte do modelo. Não são o modelo em si, mas o meio pelo qual o modelo é editado. Os Comandos são usados para executar todas as mudanças que não podem ser desfeitas do usuário. O ideal é que os comandos saibam somente sobre o modelo. Devem evitar fazer referência a uma EditPart ou figura. De forma semelhante, um comando deve evitar chamar a interface com o usuário (como um diálogo pop-up) sempre que possível.

Uma História de Dois Modelos

Uma aplicativo GEF direto é um editor para desenhar diagramas. (Aqui, diagrama significa apenas uma figura, não um diagrama de classes, etc.) Um diagrama pode ser modelado em algumas formas. Uma forma pode ter propriedades para local, cor, etc., e pode ser uma estrutura de grupo de diversas formas. Não há nenhuma surpresa aqui e o requisito anterior é facilmente mantido (consulte a Figura 2).

Outro aplicativo GEF comum é um editor UML, como um editor de diagramas de classes. Uma informação importante no diagrama é o local (x, y) onde uma classe aparece. Baseado na seção anterior, você pode supor que o modelo deva descrever uma classe como tendo uma propriedade x e y . A maioria dos desenvolvedores deseja evitar preencher o modelo com atributos que não fazem sentido. Nesses aplicativos, o termo modelo de "negócios" pode ser usado para fazer referência ao modelo base no qual os detalhes de semântica importantes são armazenados. Apesar de informações específicas do diagrama serem armazenadas no modelo de "visualização" (que significa uma "visualização" de algo no modelo de negócios), um objeto pode ser visualizado diversas vezes em um diagrama. Às vezes, a divisão é refletida até na área de trabalho, onde diferentes recursos podem ser usados para persistir o diagrama e o modelo de negócios separadamente. Pode haver até diversos diagramas para o mesmo modelo de negócios (consulte a Figura 3).

Se seu modelo é dividido em duas partes ou mesmo em diversos recursos não importa para a GEF. O termo modelo é usado para fazer referência a todo o modelo do aplicativo. Um objeto na tela pode corresponder a diversos objetos no modelo. GEF foi projetada para permitir que o desenvolvedor trate desses mapeamentos de forma fácil.

Estratégias de Notificação

As atualizações da visualização devem quase sempre ser resultado de notificação do modelo. Seu modelo deve fornecer algum mecanismo de notificação e esse mecanismo deve ser mapeado para as atualizações apropriadas em seu aplicativo. As exceções podem ser os modelos somente leitura ou modelos que não podem notificar, como um sistema de arquivos ou uma conexão remota.

As estratégias de notificação são geralmente distribuídas (por objeto) ou centralizadas (por domínio). Um notificador de domínio conhece cada mudança de qualquer objeto do modelo e transmite essas mudanças para listeners do domínio. Se seu aplicativo empregar esse modelo de notificação, você provavelmente incluirá um listener de domínio por visualizador. quando esse listener recebe uma mudança, consultará a(s) EditPart(s) afetada(s) e, em seguida, efetuará novo dispatch da mudança conforme necessário. Se seu aplicativo usar notificação distribuída, cada EditPart geralmente incluirá seus próprios listeners nos objetos do modelo que afetarem as mesmas.

Voltar para parte superior

Etapa 2. Definir a Visualização

A próxima etapa é decidir como você exibirá seu modelo usando figuras do plug-in Draw2D. Algumas figuras podem ser usadas diretamente para exibirem um dos objetos de seu modelo. Por exemplo, a figura Rótulo pode ser usada para exibir uma Imagem e string. Às vezes, os resultados desejados podem ser obtidos compondo diversas figuras, gerenciadores de layout e/ou bordas. Por fim, você pode acabar escrevendo suas próprias implementações de figuras que são exibidas de maneira específica para seu aplicativo.

Informações adicionais sobre como compor ou implementar figuras e layouts podem ser localizadas no guia de desenvolvedores do Draw2D fornecido no GEF SDK.

Ao usar o Draw2D com a GEF, pode facilitar o gerenciamento de seu projeto e flexibilizar ainda mais seus requisitos de mudança, seguindo estas diretrizes:

• Não reinvente a roda. É possível combinar os gerenciadores de layout fornecidos para renderizar a maioria das coisas. Considere compor diversas figuras usando combinações do layout da barra de ferramentas (em orientação vertical ou horizontal) e do layout de borda. Somente como um último recurso você deve escrever seu próprio gerenciador de layout. Como um ponto de referência, consulte a paleta fornecida na GEF. A paleta é renderizada usando muitas das figuras e layouts padrão do Draw2D.
• Mantenha uma separação limpa entre EditPart e a figura. Se sua EditPart usar uma estrutura composta com diversas figuras, layouts e/ou bordas, mantenha o máximo desses detalhes ocultos da EditPart. É possível (mas não é uma boa idéia) fazer com que a EditPart construa tudo. Mas fazer isso não leva a uma separação limpa entre o controlador e a visualização. A EditPart tem conhecimento íntimo da estrutura de figura, portanto, reutilizar essa estrutura com uma EditPart não é possível. Além disso, alterar a aparência ou estrutura pode levar a erros inesperados. Em vez disso, você deve gravar suas próprias subclasses da Figura que oculta os detalhes de sua estrutura. Em seguida, defina a API mínima nessa subclasse que a EditPart (o controlador) usa para atualizar a visualização. Essa prática, referida como separation of concerns, resulta em maior reutilização e menos erros.
• Não faça referência ao modelo ou EditPart a partir da figura. A figura não deve ter acesso à EditPart nem ao modelo. Em algumas situações, a EditPart pode ser incluída como um listener na figura, mas será conhecida somente como um listener, não como a EditPart. Essa prática de desacoplagem também resulta em maior reutilização.
• Use uma área de janela de conteúdo. Às vezes há um contêiner que conterá outros elementos gráficos, mas você precisa de decorações em torno da parte externa do contêiner. Por exemplo, uma classe UML é geralmente mostrada como uma caixa, em que a parte superior é rotulada com o nome da classe e possivelmente alguns estereótipos e a parte inferior é reservada para atributos e métodos. Isso pode ser feito compondo diversas figuras. A primeira figura é a caixa de título para a classe, enquanto que outra figura é designada como a área de janela de conteúdo. Essa figura conterá, eventualmente, as figuras para atributos e métodos. Ao gravar a implementação da EditPart posteriormente, é trivial indicar que a área de janela de conteúdo deve ser usada como pai para todos os elementos filhos.

Voltar para parte superior

Etapa 3. Escrever suas EditParts, os Controladores

Em seguida, faremos a ponte entre o modelo e a visualização com o controlador ou EditPart. Esta etapa que coloca a "estrutura" na GEF. As classes fornecidas são abstratas, portanto, os cliente devem realmente escrever código. Na verdade, o uso de subclasse não é apenas familiar, mas é provavelmente a maneira mais flexível e direta para mapear do modelo para a visualização.

Há três implementações base fornecidas para o uso de subclasse. Use AbstractTreeEditPart para EditParts que aparecem no visualizador em árvore. Estenda AbstractGraphicalEditPart e AbstractConnectionEditPart em visualizadores gráficos. Vamos focar EditParts gráficas aqui. Os mesmos princípios se aplicam ao uso no visualizador em árvore.

Ciclo de Vida da EditPart

Antes de gravar suas EditParts, ajuda saber de onde elas vêm e para onde vão quando não são mais necessárias. Cada visualizador é configurado com um factory para criar EditParts. Ao configurar o conteúdo do visualizador, você faz isso fornecendo o objeto modelo que representa a entrada para esse visualizador. A entrada geralmente é o objeto modelo mais acima, a partir do qual todos os outros objetos podem ser transferidos. O visualizador usa, então, seu factory para construir a EditPart de conteúdo para esse objeto de entrada. A partir de então, cada EditPart no visualizador preencherá e gerenciará suas próprias EditParts filhas (e de conexão), delegando ao factory da EditPart quando novas EditParts são necessárias, até o visualizador ser preenchido. À medida que novos objetos modelos são incluídos pelo usuário, as EditParts nas quais esses objetos aparecem responderão construindo as EditParts correspondentes. Observe que a visão da visualização faz um paralelo com a construção das EditParts. Portanto, após cada EditPart ser construída e incluída em sua EditPart pai, o mesmo ocorre com a visualização, sejam figuras ou itens da árvore.

As EditParts são eliminadas assim que o usuário remove o objeto modelo correspondente. Se o usuário desfizer uma exclusão, é uma EditPart diferente que é recriada para representar o objeto restaurado. Por isso as EditParts não podem conter informações de longo prazo e não devem ser referidas por comandos.

Sua Primeira EditPart: A EditPart de Conteúdo

A primeira EditPart escrita é a EditPart que corresponde ao próprio diagrama. Essa EditPart é referida como o conteúdo do visualizador. Corresponde ao elemento mais acima no modelo e é filha da EditPart raiz do visualizador (consulte a Figura 4). A raiz é a base para o conteúdo, fornecendo diversas camadas gráficas, como camadas de conexão, camadas de identificador, etc. e, possivelmente, zoom ou outra funcionalidade no nível do visualizador. Observe que as funções da raiz não dependem de nenhum objeto de modelo e que a GEF fornece implementações prontas para o uso para raízes.

A figura do conteúdo não é muito interessante e, frequentemente, é apenas um painel vazio que conterá os filhos do diagrama. Sua figura deve ser opaca e deve ser inicializada com o gerenciador de layout que fará o layout dos filhos dos diagramas. Terá, no entanto, estrutura. Os filhos imediatos do diagrama são determinados pela lista de objetos modelos filhos retornados. A Lista 1 mostra uma EditPart de conteúdo de amostra que cria uma figura opaca que posicionará seus filhos usando XYLayout.

                
public class DiagramContentsEditPart extends AbstractGraphicalEditPart {
    protected IFigure createFigure() {
        Figure f = new Figure();
        f.setOpaque(true);
        f.setLayoutManager(new XYLayout());
        return f;
    }
    protected void createEditPolicies() {
        ...
    }
    protected List getModelChildren() {
        return ((MyModelType)getModel()).getDiagramChildren();
    } }

Para determinar os itens no diagrama, o método getModelChildren() é implementado. Esse método retorna a lista de objetos modelos filhos, como os nós no diagrama. A superclasse usará essa lista de objetos modelos para criar as EditParts correspondentes. As novas EditParts criadas são incluídas na lista de EditParts filhas da parte. Isso, por sua vez inclui a figura de cada filha na figura do diagrama. Por padrão, uma lista vazia seria retornada, o que indicaria nenhuma filha.

Mais EditParts Gráficas

Suas EditParts remanescente (representando os itens no diagrama) provavelmente terão dados para serem exibidos graficamente. Também podem ter sua própria estrutura, como conexões ou seus próprios filhos. Muitos aplicativos GEF representam ícones rotulados com conexões entre eles. Vamos supor que sua EditPart irá usar um Rótulo como sua figura e que o modelo forneça um nome, ícone e conexões para e a partir do rótulo. A Lista 2 mostra uma primeira passagem da implementação desse tipo de EditPart.

                
public class MyNodeEditPart extends AbstractGraphicalEditPart {
    protected IFigure createFigure() {
        return new Label();
    }
    protected void createEditPolicies() {
        ...
    }
    protected List getModelSourceConnections() {
        MyModel node = (MyModel)getModel();
        return node.getOutgoingConnections();
    }
    protected List getModelTargetConnections() {
        MyModel node = (MyModel)getModel();
        return node.getIncomingConnections();
    }
    protected void refreshVisuals() {
        MyModel node = (MyModel)getModel();
        Label label = (Label)getFigure();
        label.setText(node.getName());
        label.setIcon(node.getIcon());
        Rectangle r = new Rectangle(node.x, node.y, -1, -1);
        ((GraphicalEditPart) getParent()).setLayoutConstraint(this, label, r);
    } }

Um novo método, refreshVisuals(), é substituído. Esse método é chamado quando está na hora de atualizar a figura usando dados do modelo. Nesse caso, o nome e ícone do modelo são refletidos no rótulo. Mas o mais importante, o rótulo é posicionado passando suas restrições de layout para o pai. Na EditPart de conteúdo, usamos um gerenciador de layout XY. Esse layout usa uma restrição em Retângulo para determinar onde posicionar as figuras filhas. Uma largura e altura de "-1" indicam que a figura deve receber seu tamanho preferencial.

O método refreshVisuals() é chamado somente uma vez durante a inicialização da EditPart e nunca mais é chamado. Ao responder à notificação do modelo, é responsabilidade do aplicativo chamar refreshVisuals() novamente, conforme necessário, para atualizar a figura. Para melhorar o desempenho, você pode querer fatorar o código para cada atributo do modelo em seu próprio método (ou um único método com um "comutador"). Dessa forma, quando o modelo notifica, você executa a menor quantidade de código para atualizar somente o que foi alterado.

A outra diferença interessante é o código para suporte à conexão. Semelhante a getModelChildren(), getModelSourceConnections() e getModelTargetConnections() devem retornar os objetos modelos que representam os links entre nós. A superclasse cria as EditParts correspondentes quando necessário e inclui as mesmas na lista de EditParts de conexão de origem e de destino. Observe que uma conexão é referida pelos nós em cada extremidade, mas sua EditPart precisa ser criada somente uma vez. A GEF assegura que uma conexão seja criada somente uma vez, verificando primeiro se já existe no visualizador.

Fazendo Conexões

Escrever uma implementação da EditPart de conexão não é muito diferente. Inicie efetuando subclasse de AbstractConnectionEditPart. Como antes, refreshVisuals() pode ser implementado para mapear atributos do modelo para a figura. Uma conexão também pode ter uma restrição, apesar de as restrições serem ligeiramente diferentes de antes. Aqui, as restrições são usadas pelos roteadores de conexão para dobrar a conexão. Além do mais, a figura de uma EditPart de conexão deve ser uma Connection do Draw2D, que introduz mais um requisito: âncoras de conexão.

Uma conexão deve ser ancorada em ambas as extremidades por uma ConnectionAnchor. Portanto, você deve indicar, na EditPart de conexão ou nas implementações de nó, quais âncoras usar. Por padrão, a GEF supõe que as EditParts de nó fornecerão as âncoras implementando a interface NodeEditPart . Uma razão para isso é que a opção de âncora depende da figura que está sendo usada pelos nós em cada extremidade. A EditPart de conexão não deve ter conhecimento de nada sobre as figuras que estão sendo usadas pelo nós. Outra razão é que quando o usuário estiver criando uma conexão, a EditPart de conexão não existe, de forma que o nó deve ser capaz de mostrar feedback por conta própria. Continuando com a Lista 2, incluímos o suporte necessário à âncora na Lista 3.

                
public class MyNodeEditPart
    extends AbstractGraphicalEditPart
    implements NodeEditPart {
    ...
    public ConnectionAnchor getSourceConnectionAnchor(ConnectionEditPart connection) {
        return new ChopboxAnchor(getFigure());
    }
    public ConnectionAnchor getSourceConnectionAnchor(Request request) {
        return new ChopboxAnchor(getFigure());
    }
    public ConnectionAnchor getTargetConnectionAnchor(ConnectionEditPart connection) {
        return new ChopboxAnchor(getFigure());
    }
    public ConnectionAnchor getTargetConnectionAnchor(Request request) {
        return new ChopboxAnchor(getFigure());
    }
    ...
}

Os métodos que aceitam uma conexão são aqueles usados ao configurar as âncoras em uma EditPart de conexão existente. Os dois outros métodos aceitam um Pedido. Esses métodos são usados durante a edição quando o usuário estiver criando uma nova conexão. Para este exemplo, uma âncora chopbox é retornada em todos os casos. Uma âncora chopbox apenas localiza o ponto no qual uma linha faz a interseção com a caixa delimitadora da figura do nó.

A implementação da EditPart de conexão é relativamente direta. Observe que não é necessário até criar a figura, já que a criação padrão de PolylineConnection é adequada para a maioria dos usos (consulte a Lista 4).

                
public class MyConnectionEditPart extends AbstractConnectionEditPart {
    protected void createEditPolicies() {
        ...
    }
    protected void refreshVisuals() {
        PolylineConnection figure = (PolylineConnection)getFigure();
        MyConnection connx = (MyConnection)getModel();
        figure.setForegroundColor(MagicHelper.getConnectionColor(connx));
        figure.setRoutingConstraint(MagicHelper.getConnectionBendpoints(connx));
    } }

Atendendo o Modelo

Após a criação, uma EditPart deve começar a atender notificações de mudanças do modelo. Como GEF é um modelo neutro, todo os aplicativos devem incluir seus próprios listeners e tratar das notificações resultantes. Quando a notificação é recebida, o manipulador pode chamar um dos métodos fornecidos para forçar uma atualização. Por exemplo, se um filho tiver sido excluído, chamar refreshChildren() fará com que a EditPart correspondente e sua figura sejam removidas. Para mudanças simples de atributos, refreshVisuals() pode ser usado. Conforme mencionado anteriormente, esse método pode ser fatorado em diversas partes para evitar atualizações desnecessárias de cada atributo exibido.

Incluir listeners e esquecer de removê-los é uma causa frequente de fugas de memória. Por essa razão, o ponto no qual você inclui e remove listeners está claramente determinado na API. Suas EditParts devem estender activate() para incluir quaisquer listeners que devem ser removidos posteriormente. Remova esses mesmos listeners estendendo deactivate(). A Lista 5 mostra as inclusões na implementação da EditPart do nó para notificação de modelo.

                
public class MyNodeEditPart extends AbstractGraphicalEditPart
    implements NodeEditPart, ModelListener {
    ...
    public void activate() {
        super.activate();
        ((MyModel)getModel()).addModelListener(this);
    }
    public void deactivate() {
        ((MyModel)getModel()).removeModelListener(this);
        super.deactivate();
    }
    public void modelChanged(ModelEvent event) {
        if (event.getChange().equals("outgoingConnections"))
            refreshSourceConnections();
        else if (event.getChange().equals("incomingConnections"))
            refreshTargetConnections();
        else if (event.getChange().equals("icon")
          || event.getChange().equals("name"))
            refreshVisuals();
    }
    ...
}

Editando o Modelo

Até o momento, cobrimos como EditParts são criadas, como elas criam seus visuais e como se atualizam quando o modelo é alterado. Além disso, as EditParts também são os principais participantes das mudanças no modelo. Isso ocorre quando um pedido para um comando é enviado à EditPart. Pedidos também são usados para solicitar que as EditParts mostrem feedback, como durante um arraste de mouse. A EditPart suporta, evita ou ignora um determinado pedido. Os tipos de pedidos que são suportados ou evitados determinam o comportamento da EditPart.

O foco, até o momento, tem sido o mapeamento da estrutura e das propriedades do modelo na visualização. Na verdade, isso é basicamente tudo que se faz na classe da EditPart em si. Seu comportamento é determinado por um conjunto de auxiliares plugáveis chamados EditPolicies. Nos exemplos fornecidos, ignoramos o método createEditPolicies(). Ao implementar esse método, você terá praticamente terminado com sua EditPart. É claro que você ainda precisará editar políticas que saibam como modificar o modelo de seu aplicativo.

Como o comportamento de edição é plugável, ao desenvolver suas diversas implementações da EditPart, é possível criar uma hierarquia de classes baseada em torno da tarefa de mapeamento do modelo para as atualizações do modelo de visualização e manipulação.

Voltar para parte superior

Etapa 4. Juntar Tudo

Neste ponto, você tem todas as partes necessárias para exibir graficamente seu modelo. Para a montagem final, estaremos usando uma IEditorPart. No entanto, os visualizadores da GEF também podem ser usados em visualizações, diálogos ou simplesmente em praticamente qualquer lugar em que você pode posicionar um controle. Para esta etapa, você deve ter seu plug-in de UI, que definirá o editor a a extensão de arquivo para os recursos que estão sendo abertos. Seu modelo pode ser definido no mesmo plug-in ou em um separado. Você também precisará de um modelo já preenchido, já que ainda não há ainda nenhuma funcionalidade de edição.

Há diversas maneiras de fornecer dados de modelo de amostra. Para a finalidade deste exemplo, iremos criar o modelo em código quando o editor for aberto, ignorando o conteúdo real do arquivo. Para fazer isso, vamos supor a existência de um factory de teste. Como alternativa, é possível criar um assistente de exemplo que preencha o recurso com dados (os assistentes normais simplesmente criariam um diagrama vazio). Por fim, você pode ser capaz de gravar o conteúdo do documento à mão com um editor de texto.

Agora que você tem um modelo de amostra, vamos criar a parte do editor que exibirá o modelo. Uma maneira rápida de iniciar é criar a subclasse ou copiar, da GEF, GraphicalEditor. Essa classe cria uma instância de ScrollingGraphicalViewer e constrói uma tela para funcionar como controle do editor. É uma classe de conveniência fornecida para ajudá-lo a começar com a GEF; um editor Eclipse com comportamento apropriado possui muitas outras coisas a serem consideradas, como ambientes de equipes pessimistas, exclusão ou deslocamento do recurso, etc.

A Lista 6 mostra uma implementação do editor de amostra. Há diversos métodos abstratos que devem ser implementados. Para o escopo deste artigo, estaremos ignorando a persistência do modelo e os marcadores. Você deve fazer duas coisas para que seu diagrama apareça no visualizador gráfico. Primeiro, configurar o visualizador com seu próprio factory de EditPart para construir EditParts a partir da Etapa 3. Em seguida, passar o objeto modelo do diagrama para o visualizador.

                
public class MyEditor extends GraphicalEditor {
    public MyEditor() {
        setEditDomain(new DefaultEditDomain(this));
    }
    protected void configureGraphicalViewer() {
        super.configureGraphicalViewer(); //Configura o \
        plano de fundo do visualizador para Sistema "white"
        getGraphicalViewer().setEditPartFactory(new MyGraphicalEditpartFactory());
    }
    protected void initializeGraphicalViewer() {
        getGraphicalViewer().setContents(MagicHelper.constructSampleDiagram());
    }
    public void doSave(IProgressMonitor monitor) {
        ...
    }
    public void doSaveAs() {
        ...
    }
    public void gotoMarker(IMarker marker) {
        ...
    }
    public boolean isDirty() {
        ...
    }
    public boolean isSaveAsAllowed() {
        ...
    } }

Voltar para parte superior

Próximas Etapas

Fomos de ter apenas um modelo até exibir esse modelo em um editor gráfico. Mas fizemos apenas a base. Mencionamos as políticas de edição de leve. É possível obter informações adicionais sobre as políticas de edição lendo a documentação do desenvolvedor fornecida com o GEF SDK. Há também um exemplo disponível na página inicial da GEF (consulte Recursos) que demonstra o uso de cada tipo de política de edição.

GEF também fornece uma paleta. A paleta exibe um conjunto de ferramentas para criar objetos no diagrama. O usuário pode ativar ferramentas diretamente a partir da paleta usando arrastar e soltar nativo. A customização do conteúdo pelo usuário também é suportada.

Diversas ações JFace também estão disponíveis na GEF. Coisas, como desfazer, alinhar, excluir, etc., podem ser usadas por seu aplicativo em menus, barras de ferramentas ou menus de contexto.

Por fim, seu aplicativo deve suportar a visualização da estrutura de tópicos e a visualização de propriedades. A visualização da estrutura de tópicos é usada para propósitos de navegação e edição limitada. O TreeViewer e/ou a janela de visão geral da GEF também podem ser usados aqui. A folha de propriedade permite que o usuário veja e edite as propriedades detalhadas do que estiver atualmente selecionado.

Para mostrar a seleção e permitir que o usuário faça as mudanças, você deve incluir políticas de edição em suas EditParts. Consulte o exemplo da página inicial da GEF e também consulte a documentação do desenvolvedor incluída com o GEF SDK.

Detalhes sobre recursos adicionais fornecidos pela GEF e o ambiente de trabalho Eclipse vão além do escopo deste artigo, mas você pode estar interessado em conhecer um pouco sobre eles:

• Paleta -- Uma paleta de ferramentas é o meio de fato para criar novos objetos em um diagrama. A GEF inclui uma paleta rica, que suporta arrastar e soltar, diversas camadas e configurações de layout, além de customização de conteúdo pelo usuário, se o aplicativo precisar.
• Barras de ação -- Editores e Visualizações podem contribuir com Ações para as barras de ferramentas, menus e menus de contexto. A GEF fornece diversas implementações de ações reutilizáveis, mas o aplicativo é responsável por exibi-las em algum lugar.
• Folha de propriedade -- A folha de propriedade pode ser usada para exibir detalhes de propriedades dos itens selecionados. A GEF permite incluir suporte à folha de propriedade na EditPart ou no modelo.
• Estrutura de tópicos -- A visualização da estrutura de tópicos é frequentemente usada para mostrar uma representação estrutural do diagrama, mas pode ser usada para qualquer coisa em geral. TreeViewer da GEF é frequentemente usado na visualização da estrutura de tópicos.

Recursos

Aprender

• Uma versão atualizada deste artigo, intitulada " Criar um Aplicativo Baseado no Eclipse Usando Graphical Editing Framework" foi publicada em março de 2007. Esta versão original permanecerá disponível para propósito de referência. Leia o novo artigo para entender os recursos mais recentes em GEF.
  
  
• O Projeto Eclipse é o host para o ambiente de trabalho Eclipse, a GEF e outras tecnologias de software livre.
  
  
• Verifique a " Lista de Leitura Recomendada do Eclipse."
  
  
• Navegue por todo o Conteúdo do Eclipse em developerWorks.
  
  
• Iniciante para o Eclipse? Leia o arquivo do developerWorks " Introdução à Plataforma Eclipse" para conhecer sua origem e arquitetura e como estender o Eclipse com plug-ins.
  
  
• Expanda suas qualificações no Eclipse verificando, no IBM developerWorks, Recursos do Projeto Eclipse.
  
  
• Para ouvir entrevistas e discussões interessantes para desenvolvedores de software, verifique os podcasts do developerWorks.
  
  
• Para uma introdução à plataforma Eclipse, consulte " Introdução à Plataforma Eclipse."
  
  
• Mantenha-se atualizado com Eventos Técnicos e Webcasts do developerWorks.
  
  
• Assista e aprenda sobre as tecnologias IBM e de software livre e funções de produtos gratuitamente com os Demos On Demand do developerWorks.
  
  
• Verifique conferências, feiras comerciais, webcasts e outros Eventos futuros no mundo que sejam de interesse de desenvolvedores de software livre da IBM.
  
  
• Visite Zona de Software Livre do developerWorks para obter informações extensivas sobre como executar ações, sobre ferramentas e atualizações de projetos para ajudá-lo a se desenvolver com tecnologias de software livre e usá-las com produtos IBM.
  
  

Obter produtos e tecnologias

• Faça download do plug-in e localize informações adicionais sobre GEF.
  
  
• Verifique os downloads de tecnologia do Eclipse mais recentes em IBMalphaWorks.
  
  
• Faça download de Plataforma Eclipse e Outros Projetos da Eclipse Foundation.
  
  
• Faça download de versões de avaliação de produtos IBMe entre em contato com ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2®, Lotus®, Rational®, Tivoli®e WebSphere®.
  
  
• Inove seu próximo projeto de desenvolvimento de software livre com software de avaliação da IBM, disponível para download ou em DVD.
  
  

Discutir

• O grupo de notícias da GEF é um ótimo local para encontrar respostas e fazer perguntas.
  
  
• Os grupos de notícias da Plataforma Eclipse devem ser sua primeira parada para discutir questões referentes ao Eclipse. (Selecionar isso ativará seu aplicativo leitor de notícias Usenet padrão e abrirá eclipse.platform.)
  
  
• Os grupos de notícias do Eclipse têm muitos recursos para pessoas interessadas em usar e estender o Eclipse.
  
  
• Participe de blogs do developerWorks e envolva-se na comunidade developerWorks.
  
  

Sobre o autor

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Visão Geral de GEF
• Etapa 1. Trazer seu Próprio Modelo
• Etapa 2. Definir a Visualização
• Etapa 3. Escrever suas EditParts, os Controladores
• Etapa 4. Juntar Tudo
• Próximas Etapas
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais