DClick

Arquivos da categoria "Eclipse"

ToDo / FixMe plugin para Flex

Categorias relacionadas: Eclipse, Flex

Precisei e achei na net plugin para Flex que vai adicionar na lista do TASK para Eclipse ToDo e FixMe comentarios.
Acho que é “must-have” pra todos que usam Flex.

Download FlexBuilder Task Plugin

Descompactar e só jogar no PASTA_DE_ADOBE/eclipse/plugins

Por Emil Beli em 6/October/2008
Nenhum Comentário »


No Translations

Shortcuts - Menos mouse!

Categorias relacionadas: Eclipse, Flex, Java

Eis os atalhos que podem evitar alguns “lags” no posicionamento do ponteiro do mouse:

Flex builder shortcuts

http://ic.macromedia.com/ic/files/c88/v199/Flex%20Shortcuts.pdf

Eclipse 3.1 shortcuts

http://eclipse-tools.sourceforge.net/EclipseEmacsKeybindings_3_1.pdf

Mas aqui está a dica que vc gostaria de ouvir antes de ter vasculhado na net: Ctrl+Shift+L lista todos os atalhos envolvidos para a janela aberta. E se fizer a sequência 2 vezes seguidas, vc poderá customizar seus atalhos.

Outro atalho bem legal que vale comentar é Ctrl+3. Este atalho abre uma janela com filtro tipo autocomplete para procurar por qualquer feature do eclipse 3.

abraços

Por Rodrigo Facholi em 19/August/2008
Nenhum Comentário »


No Translations

Gremlins no Eclipse - como exterminar

Categorias relacionadas: Eclipse, Flex

Primeiro, preciso me desculpar para os erros que vão aparecer no texto. Sou estrangeiro e ainda não falo/escrevo português certinho.
Bem, voltando na vaca fria… (girias eu conheco, rsrs)

Ontem a noite, eu perdi alguns horas e dois quilos de nervos tentando resolver os problemas que eu nem deveria ter. Alguma coisa estava errada com o debugger e não podia finalizar o trabalho porque debugger não queria colaborar. Algumas coisas foram:

  • Cliquando numa linha para colocar o breakpoint, foi colocado em outra linha
  • Debugger pula as linhas
  • Mudanças no código não foram para o browser, mesmo fazendo ‘clean’
  • Sentido forte que Gremlins infestarum meu micro

Alguns de vocês podem dar arrisada, mas algumas coisas eu realmente não sabia, nem achei em nenhum lugar, até meu amigo e colega, Henrique Marino não veio explicar como acabar com sofrimento desse.
Agora vou compartilhar com vocês.

  1. Se seu código está controlado por CVS, com branches, verifica se compilador está apontando para branch no que você está trabalhando neste momento. Vai no (eclipse) Project -> Properties, seleciona Flex Compiler e veja o que está escrito no “Additional compiler arguments”. Isto deve ser razão porque debugger está pulando as linhas.
  2. Fecha todos os projetos menos aquele que você está trabalhando no momento. Clique com botão direito no projeto e escolhe “Close unrelated projects”
  3. Se você usa Jetty, como ele não está fazendo chato Deploy como JBoss, cria uma situação: as vezes, cache do browser não é limpado. Vai no Firefox e seleciona Tools -> Web developer -> Disable -> Disable cache.

Isto vai matar os Gremlins.

Espero que essas dicas vai ajudar alguem com mesmo problema

Por Emil Beli em 5/August/2008
7 Comentários »


Other Languages:

Flex Builder no Ubuntu. Testado e Aprovado.

Categorias relacionadas: Eclipse, Flex

Quando a Adobe liberou o Flex Builder Linux Alpha, muitos comentaram, mas até agora ninguém se manifestou sobre testes de verdade com ele. Eu e outro desenvolvedor aqui da DClick, insatisfeitos com o Windows Vista, resolvemos fazer um teste de verdade com Flex builder do Linux e o instalamos no Ubuntu. O processo de instalação é muito parecido com o Windows, depois que o eclipse está devidamente configurado, basta um duplo-clique no arquivo de instalação do Flex que uma caixa de diálogo muito parecida com o Windows aparece. Após alguns “next” e um “Finish” o seu Builder está pronto para ser usado.

Pra não dizer que ocorreu tudo perfeitamente, tivemos alguns problemas por causa de permissão nas pastas com usuários diferente, mas bastou um “chmod 777″ na pasta do eclipse e do flex que tudo se resolveu.
Como já foi comentado em outros lugares, o Flex Builder Linux não tem a opção de Design, mas nós não temos o habito de usá-la e por isso não está fazendo falta.

Já alteramos e compilamos vários projetos dos mais variados tamanhos e até agora tudo OK. Se encontramos algum bug voltamos aqui para avisá-los, mas por enquanto está mais que recomendado!

OBS:Lembrem-se de mudar o encoding de todos os membros da sua equipe para UTF-8!

Por David Paniz em 21/January/2008
1 Comentário »


No Translations

Integrando o ASDoc no Eclipse/Flex Builder com o ANT

Categorias relacionadas: ActionScript, Eclipse, Flex

O ASDoc é uma ferramenta da Adobe que faz com ActionScript o que o JavaDoc faz com o Java: criar documentação HTML de uma API baseado nas próprias classes que compõe essa API e em comentários em um formato padrão presentes nas mesmas.

O próprio Adobe Flex 2 Language Reference foi criado utilizando o ASDoc. Assim fica evidente como é vantajoso ter esse tipo de documentação para uma API. Uma biblioteca de componentes, por exemplo, pode ser facilmente navegável e entendida com uma documentação com esse estilo, que também pode conter exemplos compilados.

O ASDoc contudo ainda não é integrado nativamente ao Flex Builder, mas como ele é um executável de linha de comando, é fácil integra-lo com o Ant. O Ant é um plugin para o Eclipse (mas é tão utilizado que até vêm na instalação deste - mas não vem se você instalou o Flex Builder standalone) e é um utilitário para automatizar tarefas relacionadas com o desenvolvimento, como por exemplo, compilar classes Java, gerar um arquivo para deploy, realizar testes unitários, fazer FTP, etc etc, e claro, executar outros softwares, como o próprio ASDoc. A sintaxe é em XML, o que torna uma ferramenta fácil de utilizar. Há muitas referências sobre o Ant na Internet.

A instalação do ASDoc é simples, basta extrair o conteúdo do arquivo para a pasta onde está localizado o seu SDK. O ASDoc já está pronto para ser utilizado, manualmente, via linha de comando. Mas certamente há outras coisas mais importantes em um projeto para fazermos do que rodar manualmente uma ferramenta como essa. Seria o mesmo que compilar manualmente via linha de comando. É o tipo de tarefa que precisa ser automatizada. E com o Ant, além da documentação que pode ser gerada de dentro do próprio Eclipse, pode se integrar com outras tarefas, como por exemplo, só gerar se passar nos testes unitários, compactar em zip, etc.

Veja um Ant simples para automatizar:

XML:
  1. <project name="asdoc" default="create" basedir=".">
  2.     <property name="asdocExec" location="C:\Program Files\Adobe\Flex Builder 2 Plug-in\Flex SDK 2\bin\asdoc.exe" />
  3.     <property name="sourcePath" location="${basedir}/. "/>
  4.     <property name="outputPath" location="${basedir}/docs" />
  5.  
  6.     <target name="create">
  7.         <exec executable="${asdocExec}">
  8.             <arg line="-doc-sources ${sourcePath}" />
  9.             <arg line="-output ${outputPath}" />
  10.         </exec>
  11.     </target>
  12. </project>

A primeira propriedade é o local do executável do ASDoc. A segunda é o local onde estão as nossas classes e a terceira onde a documentação deve ser gerada. A proriedade "basedir" é do próprio Ant e está definida na primeira linha, na tag project. E depois vem efetivamente a tarefa, que roda o ASDoc passando os parâmetros mínimos para rodar com sucesso.

No exemplo acima, para o parâmetro -doc-sources é passado um diretório com as nossas classes, e ele percorrerá recursivamente este diretório para gerar a documentação.

Importante: O ASDoc visualiza a existência de arquivos MXML e os adiciona na documentação, mas não os lê para pegar seus comentários internos.

Uma outra possibilidade é utilizar o atributo -doc-classes, que são as classes que queremos documentar. E o ASDoc aqui faz uma coisa muito interessante: ele documenta também as classes que essa classe utiliza. Portanto, se colocarmos o arquivo principal de nossa aplicação, todas as classes utilizadas por ela serão documentadas também. O local em que o ASDoc procura pelas classes devem estar definidos no argumento -source-path. Por exemplo:

XML:
  1. <target name="create">
  2.         <exec executable="${asdocExec}">
  3.             <arg line="-doc-classes Main" />
  4.             <arg line="-source-path ." />
  5.             <arg line="-output ${outputPath}" />
  6.         </exec>
  7.     </target>

Ou ainda, caso o seu projeto faça referências a outros, você pode utilizar mais de um source-path. E essa é uma situação comum. Normalmente colocamos o Cairngorm em um projeto separado, a biblioteca de componentes em outro, etc etc. Exemplo:

XML:
  1. <arg line="-source-path '..\Cairngorm21' ." />

Há outros parâmetros disponíveis e podem ser utilizadas para customizar a documentação, como o -main-title, para alterar o título do documento, por exemplo. Abaixo um Ant de um projeto aqui da DClick:

XML:
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <project  name="asdoc" default="_generate" basedir=".">
  3.    
  4.     <property name="asdocExec" location="C:\Program Files\Adobe\Flex Builder 2 Plug-in\Flex SDK 2\bin\asdoc.exe" />
  5.     <property name="outputPath" location="${basedir}/docs" />
  6.    
  7.     <property name="additionalPaths" value="'..\DClickComponents' '..\Cairngorm21'" />
  8.     <property name="mainClass" value="Main" />
  9.  
  10.     <property name="docsTitle" value="Projeto - API Documentation" />
  11.     <property name="docsFooter" value="Copyright 2006 DClick Desenvolvimento de Software Ltda." />
  12.    
  13.     <target name="_generate" depends="delete,create,open"/>
  14.  
  15.     <target name="delete">
  16.         <delete dir="${outputPath}" includeEmptyDirs="true"/>
  17.         <mkdir dir="${outputPath}" />
  18.     </target>
  19.  
  20.     <target name="create">
  21.         <exec executable="${asdocExec}" failonerror="true">
  22.             <arg line="-main-title '${docsTitle}'" />
  23.             <arg line="-window-title '${docsTitle}'" />
  24.             <arg line="-footer '${docsFooter}'" />
  25.            
  26.             <arg line="-doc-classes ${mainClass}" />
  27.            
  28.             <arg line="-source-path ${additionalPaths} ." />
  29.             <arg line="-output ${outputPath}" />
  30.         </exec>
  31.     </target>
  32.    
  33.     <target name="open">
  34.         <exec executable="cmd">
  35.             <arg line="/c" />
  36.             <arg line="${outputPath}\index.html" />
  37.         </exec>
  38.     </target>
  39.  
  40. </project>

Normalmente rodamos a tarefa "_generate", que dispara as demais tarefas: a primeira (delete) para limpar o diretório e assim remover arquivos não mais utilizados, a segunda (create) que efetivamente chama o ASDoc, e a terceira (open) que abre o arquivo principal da documentação na máquina do desenvolvedor.

Notem os argumento de customização (main-title, window-title, footer), a classe principal (Main, que na verdade é o Main.mxml, presente na raiz), e os paths adicionais em source-paths (do projeto DClickComponents e do projeto Cairngorm21).

O ASDoc é uma boa ferramenta e certamente irá evoluir, como dar suporte para geração de comentários a partir de MXML (não muito útil para telas, mas de extrema importância para componentes) e possivelmente uma maior integração com o Flex Builder. O Ant certamente nos facilita um bocado com automatização e assim podemos utilizar o nosso tempo para atividades mais importantes. O conceito e a ferramenta também podem ser utilizados para compilar arquivos do Flex com o SDK, sem a necessidade do Flex Builder (mas ainda utilizando o Eclipse como IDE).

Por Fabio Terracini em 4/December/2006
5 Comentários »


No Translations