post que explica como exportar o fxpl de um “menu wizard” no catalyst. Neste post você vai ver como importar o arquivo fxpl, criar um skin para o ButtonBar, modificar e aplicar o skin criado pelo Eduardo no novo skin do ButtonBar.

Para quem ainda não viu o screencast do Beck sobre skins, vale a pena conferir. Neste screencast o Beck foca bastante no skin do Button, e mostra as regras básicas para se criar um skin. Como o post do Eduardo fala sobre um ButtonBar, irei focar neste componente.

Antes de mais nada, vamos olhar a documentação do ButtonBar:



Pela documentação fica claro que o skin default do ButtonBar (spark.skins.spark.ButtonBarSkin) é composto por 4 partes, sendo 3 delas as partes que representam botões do ButtonBar, o primeiro botão (firstButton), os botões do meio (middleButton) e o último botão (lastButton). Vamos usar os botões que o Eduardo criou para mudar os skins dos botões.

1. Faça o download do arquivo fxpl disponibilizado pelo Eduardo.
2. Importe o fxpl no FlashBuilder




3. Após importar o arquivo, podemos ver a criação de um projeto library, que contém todos os componentes criados no Catalyst e também todos os assets necessários. Vamos nos atentar a 3 arquivos no projeto, Step1ToggleButton que vai ser o firstButton, o Step2ToggleButton que vai representar o middleButton e o Step3ToggleButton que vai ser o lastButton.





4. Após importado, vamos criar o skin do ButtonBar.






5. Agora vamos trocar os skins dos botões do WizzardButtonBarSkin que criamos no passo 4, usando os skins criado pelo Eduardo.




1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

xml version=“1.0″ encoding=“utf-8″?> “http://ns.adobe.com/mxml/2009″ ? ? ? ? ? ?? ? xmlns:s=“library://ns.adobe.com/flex/spark” ? ? ? ? ? ?? ? xmlns:mx=“library://ns.adobe.com/flex/mx” minWidth=“955″ minHeight=“600″> ? ? ? ? ? ? ? ? ? ? ? ? “{vs}” ? ? ? ? ? ? ? ?? skinClass=“components.WizarButtonBar” ? ? /> ? ? ? ? “vs”> ? ? ? ? “Step1″> ? ? ? ? ? ? ? ? ? ? ? ? ? ? text=“Wizard step 1″ /> ? ? ? ? ? ? ? ? ? ? ? ? ? ? “Step2″> ? ? ? ? ? ? ? ? ? ? ? ? ? ? text=“Wizard step 2″ /> ? ? ? ? ? ? ? ? ? ? ? ? ? ? “Step3″> ? ? ? ? ? ? ? ? ? ? ? ? ? ? text=“Wizard step 3″ /> ? ? ? ? ? ? ? ? ? ? ? ? ? ?




6. Agora é só utilizar o novo skin e ver o resultado. Lembre-se de importar a biblioteca no seu projeto Flex.




1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

“http://ns.adobe.com/mxml/2009″ ? ? ? ? ? ?? ? xmlns:s=“library://ns.adobe.com/flex/spark” ? ? ? ? ? ?? ? xmlns:mx=“library://ns.adobe.com/flex/mx” minWidth=“955″ minHeight=“600″> ? ? ? ? ? ? ? ? ? ? ? ? “{vs}” ? ? ? ? ? ? ? ?? skinClass=“components.WizarButtonBarSkin” ? ? /> ? ? ? ? “vs”> ? ? ? ? “Step1″> ? ? ? ? ? ? ? ? ? ? ? ? ? ? text=“Wizard step 1″ /> ? ? ? ? ? ? ? ? ? ? ? ? ? ? “Step2″> ? ? ? ? ? ? ? ? ? ? ? ? ? ? text=“Wizard step 2″ /> ? ? ? ? ? ? ? ? ? ? ? ? ? ? “Step3″> ? ? ? ? ? ? ? ? ? ? ? ? ? ? text=“Wizard step 3″ /> ? ? ? ? ? ? ? ? ? ? ? ? ? ?





7. Para finalizar, vamos arrumar o espaço entre os botões do ButtonBar. Para fazer isso é simples, é só editar o Skin que criamos no passo 4, e diminuir o gap do layout de -1 para -31, como segue:




1 2 3 4 5

“dataGroup” width=“100%” height=“100%”> ? ? ? ? ? ? ? ? ? ? “-31″/> ? ? ? ?



A arte final fica assim:

Agora voce já sabe como criar um skin para o ButtonBar e como você pode criar uma biblioteca de componentes usando o arquivo fxpl exportado do Catalyst.

aqui a biblioteca que contém o componente, e adicioná-la na pasta libs do seu projeto.

2. Agora precisamos incluir a classe principal do componente no Application do nosso projeto Flex.

3. Devemos extender os objetos que desejamos destacar e implementar a interface br.com.dclick.components.zoom.IZoomItem, no meu exemplo, eu extendi a classe Panel que ficou assim.

4. Observe o método useBackgroundZoomContainer():Boolean da interface IZoomItem, ele serve para auxiliar quando estamos tentando destacar um componente com fundo transparente, como no caso apresentado o meu Panel não tem um background transparente, então eu retorno false no método.

5. Aplicar a minha nova classe PanelZoom ao meu Application.

6. Executar o projeto e clicar no novo painel segurando o SHIFT para testar o efeito.

Agora já podem abusar do componente e extender qualquer tipo de componente visual. Espero que tenham gostado!

aqui a biblioteca que contém o componente, e adicioná-la na pasta libs do seu projeto.

2. Agora precisamos incluir a classe principal do componente no Application do nosso projeto Flex.

3. Devemos extender os objetos que desejamos destacar e implementar a interface br.com.dclick.components.zoom.IZoomItem, no meu exemplo, eu extendi a classe Panel que ficou assim.

4. Observe o método useBackgroundZoomContainer():Boolean da interface IZoomItem, ele serve para auxiliar quando estamos tentando destacar um componente com fundo transparente, como no caso apresentado o meu Panel não tem um background transparente, então eu retorno false no método.

5. Aplicar a minha nova classe PanelZoom ao meu Application.

6. Executar o projeto e clicar no novo painel segurando o SHIFT para testar o efeito.

Agora já podem abusar do componente e extender qualquer tipo de componente visual. Espero que tenham gostado!

Todos sabemos que com a vinda do Flash Builder 4 nós ganhamos o suporte a visualização do ASDoc, mas algo que deixou a desejar foi na criação de novas libs através do Flex Library Project pois não há como adicionar o conteúdo do ASDoc sem que haja a inclusão dos sources dentro da lib.

Essa situação não agrada muito quando o seu objetivo é distribuir uma biblioteca que tenha todo o suporte do ASDoc mas que não contenha os sources do seu projeto, visando manter a propriedade intelectual do que está sendo distribuído.

Reconhecido o erro, a Adobe liberou um Ant simples que você pode usar em seus Flex Library Projects.

O Ant faz as seguintes ações:
1. Compila o SWC.
2. Compila o ASDoc.
3. Adiciona ao SWC os novos xml/DITA gerados pelo ASDoc.

Entendido o problema, segue o Ant feito pela adobe com algumas modificações.
(Observem os comentários e não esqueça de substituir o CAMINHO_PARA_O_FLEXTASKS.JAR e o CAMINHO_PARA_A_SDK_DO_FLEX)

Agora que já entendemos o problema e já temos a solução, que tal automatizar o processo? Vamos adicionar o Ant no processo automático de compilação do projeto.

1. Adicione o ant dentro do path do seu projeto.

2. Acesse as propriedades do projeto e vá em Builders.

2. Clique no botão import e adicione o Ant file.

3. Desmarque a opção Flex.

Pronto, agora seu projeto Flex Library já está pronto para compilar o seu ASDoc sem comprometer o source dos seus arquivos.

Para baixa o ant clique aqui.

Durante o ando de 2010 diversos leitores me escreveram solicitando alguma forma de “receita de bolo” para a criação de projetos em Flex. Estavam buscando uma maneira de criar uma aplicação de forma que fosse mais correta e mais fácil, baseada em padrões de projeto e definida através de uma estrutura que facilitasse o desenvolvimento.

No início de 2011 comecei a pensar mais no assunto, pois irei implementar estas regras nos próximos livros, chegando a uma série de “regras” das quais estarei apresentando neste artigo. Inicialmente, queria dizer que eu não sou o dono da verdade, e estou longe de criar alguma regra que se não usada irá causar o seu insucesso. Estou disposto a receber críticas que sejam construtivas, com o intuito de melhorar o sistema cada vez mais, possibilitando assim que a comunidade tenha em mãos um bom documento para consulta.

PHP ou Java?

Uma das perguntas que mais recebi ao longo de 2010, por isso estarei discutindo um pouco sobre qual linguagem de servidor usar. Inicialmente você deve saber que não é a linguagem que vai fazer você ter sucesso ou não em um sistema, e sim o quanto você conhece a mesma. Por exemplo, se você conhece muito bem PHP, porque aventurar-se em Java se dá conta do recado? O mesmo vale para o Java, mas não recebi emails de nenhum programador Java querendo mudar para php… (sic.. hehe).

O que? é fato nesta “briguinha” é que, não existe melhor ou pior. Java é mais complexo que php, exige mais atenção mas traz muitos benefícios, até financeiros (sim você ganha mais). PHP é mais fácil, você cria tudo mais rápido e com isso fica mais feliz Qual você vai escolher? Escolha a que te faz mais feliz.

Zend_AMF ou AMFPHP ?

Outra dúvida muito comum entre os programadores PHP. Eu costumo selecionar um ou outro dependendo do projeto em sí. Se o seu projeto vai usar alguns recursos do Zend Framework, e são muitos, utilize o Zend_AMF. Caso contrário, use AMFPHP.? Aqui chegamos a um impasse do qual julgo ser mais importante do que a briga entre Zend e AMFPHP: você ainda pensa em criar um projeto sem o Zend Framework? Você irá criar tudo que precisa “na mão” ou vai usar componentes de terceiros? Falo isso porque se um projeto em PHP é iniciado, o uso do Zend Framework irá acelerar muito o processo do mesmo. Rotinas como enviar email, acessar a sessão do php, gerenciar usuários com ACL, persistência de dados, acesso ao twitter… são todos muito bem implementados com o Zend e o Zend Framework é mantido pela mesma empresa que mantém o PHP, então não existe biblioteca mais segura em termos de continuidade do que esta.

E quais tecnologias vamos usar nas “melhores práticas” ?

Agora que discutimos as duas perguntas mais perguntadas em 2010 vamos a esta solução que julgo, pessoalmente, ser muito boa:

No cliente:

• Adobe Flash Burrito e Flex SDK 4.5 (Basta baixar e instalar o Flash Burrito: http://labs.adobe.com/technologies/flashbuilder_burrito/).
• SWIZ Framework (http://swizframework.org/)

No servidor:

• PHP
• Zend Framework (http://www.zend.com/community/downloads)
• WAMP Server (para rodar o PHP na própria máquina – http://www.wampserver.com/en/download.php)
• Netbeans ou Eclipse PDT – Eu estou gostando mais do Netbeans, então vou usá-lo.? (http://netbeans.org/downloads/index.html? – Versão PHP)

?

Certifique-se de ter tudo instalado, para que possamos dar prosseguimento no artigo.

Estrutura de pastas e projetos

Outra dúvida comum dos usuários, é definir a estrutura de pastas do projeto. Como instalamos o WAMP Server, ele nos fornece uma pasta onde é possível ter acesso pelo nacegador, através do endereço “localhost”. Isto é, ao acessarmos http://localhost/ o WAMP Server cuida de apontar para o diretório c:wampwww (que é o que chamamos de “document root”). Para que possamos entender a estrutura do projeto, é necessário compreender uma particularidade do Flex. Diferentemente do PHP, os arquivos que estão dentro do projeto Flex não precisam ser enviados ao servidor (os arquivos mxml, as, etc). veja que o Flex compila todos os mxml/as do projeto e gera um único arquivo swf. Este arquivo sim DEVE estar no diretório web do projeto!

Vamos então criar o projeto “melhoresPraticas” da seguinte forma:

1. Crie a pasta c:wampwwwmelhoresPraticas Este é o diretório público do projeto, acessado através de http://localhost/melhoresPraticas?????????
2. Crie a pasta c:wampwwwmelhoresPraticasclasses Este é o diretório onde iremos criar as nossas classes PHP
3. Crie a pasta c:wampwwwmelhoresPraticasvos Este é o diretório onde as classes VOs serão criadas
4. Crie a pasta c:wampwwwmelhoresPraticasZend Aqui você copia/cola o Zend framework, de forma que o arquivo melhoresPraticasZendLoader.php esteja acessível
5. No Flash Builder, crie o projeto “melhoresPraticas”. Você pode deixar o DefaultLocation como está. Não clique em Finish, clique em Next, até chegar na configuração do “Compiled Flex application location”. Ou seja, aqui você irá informar para onde os aquivos compilados do flex irão ficar. Coloque o seguinte caminho: c:wampwwwmelhoresPraticasbin-debug. Não clique em Finish, clique em Next, e em Library Path, adicione a biblioteca swiz (o arquivo swc). Em “Output folder URL”, coloque: http://localhost/melhoresPraticas/bin-debug
6. Com o projeto pronto, clique no botão RUN. Deve então surgir uma página em branco no endereço: http://localhost/melhoresPraticas/bin-debug/melhoresPraticas.html
7. No Netbenas ou no eclipse, crie o projeto php apontando para c:wampwwwmelhoresPraticas

Testando a conexão

Com os projetos prontos, iremos inicialmente realizar uma simples conexão entre o Flex e o PHP. Isso é útil para que possamos começar com trabalho “pesado”. Para conectarmos o Flex no PHP, preciamos criar uma classe de conexão no Flex, que iremos chamar de ServiceBase, e um arquivo que recebe esta conexão no PHP, que chamaremos de gateway.php.

Para criar a classe ServiceBase, use o Flash Builder e acione o menu File > New > ActionScript Class e crie a classe de acordo com a imagem a seguir:

Classe ServiceBase:

package services
{
??? import mx.controls.Alert;
??? import mx.rpc.events.FaultEvent;
??? import mx.rpc.remoting.RemoteObject;
???
??? public dynamic class ServiceBase extends RemoteObject
??? {
??????? public function ServiceBase(classe:String)
??????? {
??????????? super(“zend”);
???????????
??????????? /*
???????????? * Como o arquivo swf está na pasta bin-debug,?
???????????? * precisamos subir um nível para chegarmos ao
???????????? * arquivo gateway.php
???????????? */
??????????? this.endpoint = “../gateway.php”;
???????????
??????????? this.source = classe;
??????????? this.addEventListener(FaultEvent.FAULT,OnFault);
??????? }
???????
??????? protected function OnFault(e:FaultEvent):void
??????? {
??????????? Alert.show(e.fault.faultString,”Erro” );
??????? }
??? }
}

Esta classe tem como principal objetivo estabelecer o endpoint, que é o gateway.php que ainda vamos criar. O atributo source define qual a classe que iremos acessar na pasta classes. Também adicionamos um listener genérico caso haja alguma falha na conexão. Veja que a classe é dinâmica (dynamic), ou seja, podemos chamar métodos da classe sem que eles estejam implementados na classe. Isso é útil pois os métodos chamados nesta classe serão os métodos remotos do PHP.

No servidor, temos que criar o arquivo gateway.php, com o seguinte código:

//Adiciona o autoloader do Zend Framework
// Assim todas as classes do framework
//? serão carregadas quando precisarem
require_once “Zend/Loader/Autoloader.php”;
Zend_Loader_Autoloader::getInstance()->setFallbackAutoloader(true);

//Instancia o servidor Zend_AMF
$server = new Zend_Amf_Server();

//Habilita o modo de desenvolvimento, retornando
// mensagens de erro. Comente esta linha quando
//?? estiver em modo de produção
$server->setProduction(false);

//Adiciona este diretorio como um diretorio de
// classes que podem ser usadas pelo Flex
$server->addDirectory(dirname(__FILE__).”/classes”);
set_include_path(dirname(__FILE__).”/vos”);

//TODO: Adicionar VOs

//Dependendo da requisição do Flex, irá
// chamar a classe correspondente, respondendo
//?? em formato AMF o que a classe responder.
echo $server->handle();

//Não fechar a tag PHP, nunca !!

?

O arquivo gateway.php é o ponto de entrada para as classes em PHP. Veja que inicialmente fazemos um include do Autoloader.php para que todas as classes do Zend Framework sejam instanciadas sem a necessidade de realizar requeires. Criamos então a instância do Zend_AMF_Server, que irá cuidar para que o flex consiga conversar com o PHP via AMF. Adicionamos o diretório classes como um diretório do AMF, onde as classes serão expostas ao flex e usamos o set_include_path para adicionar as classes que estão na pasta “vos” no path global do php, para que não precisamos fazer include das mesmas. Depois adicionaremos mais código sobre as classes VOs.

Na pasta “classes”, criamos a classe Teste, e o método sayHelloWorld. O nome do arquivo tem que ser o mesmo nome da classe, ou seja, Teste.php.

class Teste {
??? public function sayHelloWorld($name)
??? {
??????? return “Hello World $name”;
??? }
}

//Não feche a tag PHP!

?

Agora voltaremos ao Flex para que ele possa acessar a classe teste. No arquivo melhoresPraticas.mxml, adicionamos o seguinte código:

?

http://ns.adobe.com/mxml/2009″
?????????????? xmlns:s=”library://ns.adobe.com/flex/spark”
?????????????? xmlns:mx=”library://ns.adobe.com/flex/mx” minWidth=”955″ minHeight=”600″>
???
??????? ??????????? import mx.controls.Alert;
??????????? import mx.rpc.events.ResultEvent;
???????????
??????????? import org.swizframework.utils.services.ServiceHelper;
???????????
??????????? import services.ServiceBase;
??????? ]]>
???
???
???
??????? ???????????
??????????? var testeService:ServiceBase = new ServiceBase(“Teste”);
??????????? var serviceHelper:ServiceHelper = new ServiceHelper();
???????
??????? serviceHelper.executeServiceCall(
??????????? testeService.sayHelloWorld(“Daniel”),
??????????? function(e:ResultEvent):void{
??????????????? Alert.show(e.result.toString());
??????????? });
???????
??????? ]]>
???
???

?

Como estamos realizando um teste, fazemos o acesso ao PHP no evento creationComplete da aplicação. Criamos a variável testeService que é do tipo ServiceBase, repassando o parâmetro que é o nome da classe no PHP, ou seja, “Teste”. Também criamos a variável serviceHelper que pertence ao Swiz e é um facilitador de acessos ao PHP. Usamos no serviceHelper? o método executeServiceCall, que irá chamar remotamente o método sayHelloWorld repassando o parâmetro “Daniel” e quando concluído, executará a função que está no segundo parâmetro, realizando um Alert.

Ao executar esta aplicação, quando é carregada surgirá a mensagem de retorno do PHP:

?

Criando as classes em Service

Com o teste de conexão realizado, podemos avançar mais no código! A primeira refatoração que faremos é em relação as classes que estão na pasta service. Até agora criamos o seguinte código:

??? var testeService:ServiceBase = new ServiceBase(“Teste”);

Ao invés de criar a instância de ServiceBase repassando uma string que é o nome da classe, iremos criar a classe TesteService, da seguinte forma:

package services
{
??? public dynamic class TesteService extends ServiceBase
??? {
??????? public function TesteService()
??????? {
??????????? super(“Teste”);
??????? }
??? }
}

Veja que, ao criarmos a classe TesteService, podemos alterar o código da aplicação principal da seguinte forma:

var testeService:TesteService = new TesteService();

Implementando o SWIZ

Um dos melhores benefícios que o SWIZ traz é a possibilidade de separar todo o código Flex em camadas, assim como é feito no padrão MVC. Se você ainda não conhece SWIZ, é melhor conhecer, pois se está lendo este artigo está procurando criar aplicações com uma qualidade melhor e não há como chegar a esse nível sem um framework. O Swiz é o o melhor em termos de custo/benefício, porque nao é o mais fácil de aprender nem o mais complicado, e nao é o mais simples e nem o mais completo. É o meio termo em tudo.

Para usarmos o SWIZ, preciamos estabelecer algumas pastas dentro do projeto Flex, que serão nossas camadas. São elas:

• config: contém os arquivos que chamamos de “bean”, que são os arquivos que fornecem informações para serem injetadas em outras classes
• controllers: contém os arquivos que “ditam” a dinamica da camada de visualização
• services: contém os arquivos que fazem o acesso ao PHP
• events: contém eventos que podem ser disparados e mediados pelo flex
• valueObjects: são os VOs que iremos usar na aplicação
• views: contém os formúlários, é a camada de visão

Na pasta config, iremos criar o arquivo Bean.mxml, com o seguinte código:

??? xmlns:fx=”http://ns.adobe.com/mxml/2009″
??? xmlns:s=”library://ns.adobe.com/flex/spark”
??? xmlns:swiz=”http://swiz.swizframework.org”
??? xmlns:services=”services.*”
??? >
???
???
???

?

Neste bean, criamos a variável “testeService”, que é o tipo TesteService. Atenção quando ao uso de letras maiúsculas e minúsculas.? Sempre voltaremos no Bean.mxml para adicionar mais variáveis e com isso, injetá-las nos formulários e controllers da aplicação. Precisamos ainda configurar o Swiz no projeto principal da aplicação (melhoresPraticas.mxml):

http://ns.adobe.com/mxml/2009″
?????????????? xmlns:s=”library://ns.adobe.com/flex/spark”
?????????????? xmlns:mx=”library://ns.adobe.com/flex/mx”
?????????????? xmlns:swiz=”http://swiz.swizframework.org”
?????????????? minWidth=”955″ minHeight=”600″ xmlns:config=”config.*”>
???
???
???????
???????????
???????????????
???????????
???????????
???????????
??????????????? ??????????????????? eventPackages=”events.*”
??????????????????? viewPackages=”views.*”
??????????????????? />
???????????
???????????
???????????
???????????????
???????????
???????????
???????
???

???

?

Esta configuração, adicionada dentro do fx:Declarations, realiza uma configuração padrão no SWIZ. Basicamente adicionamos o Bean que criamos e definimos onde as classes relacionadas a eventos e formulários ficarão. Também definimos um LOG que será apresentado na aba Console do Flex se estiver rodando em modo de Debug.

Após a configuração

Podemos por exemplo criar a tela de login, e outras telas do sistema. Deixarei o código fonte da aplicação para que você possa olhar com calma.

Pegue o código fonte aqui

Conclusão

A lista a seguir é um resumo de melhores práticas que julgo importantes

• Use módulos/sub applications somente se precisar mesmo. Não comece um projeto de 10 telas querendo usar módulos para cada tela.
• Separe sua aplicação em camadas. Você escreve mais e cria mais artigos, mas o projeto fica mais consistente.
• Você não precisa criar o arquivo services-config.xml para conectar sua app no servidor. Pode-se criar uma classe cujo o endpoint é um caminho RELATIVO ao gateway.
• Use o caminho RELATIVO sempre, para faclitar o deploy da sua app. Isto é, use “../gateway.php” ao invés de “http://localhost/gateway.php”.
• Injete o controller na view, para passar dados à ela. Se deseja enviar mensagens para a view, então use eventos
• Não injete a view no controller.
• Use o dispatcher do SWIZ.
• Use o serviceHelper do SWIZ.
• Quando criar um formulário na view, faça o databind com uma variável do controller.
• Use eventos com moderação. Particularmente eu uso os eventos para notificar a view de alguma mudança, nunca para passar dados, que é função do controller.
• Se você quer chamar um método da view pelo controller, use eventos.
• Mais?

post) em um projeto, deve ter caído em problemas de conversão de tipo, como mostrado pela imagem abaixo:

Esse erro acontece por que estamos tentando fazer 2 operações:

• 1. Atribuir o valor de user.id (Number) a proriedade text (String)
• 2. Atribuir o valor de text (String) a proriedade user.id (Number)

A primeira operação funciona muito bem, pois a classe Number tem o método toString() que é chamado toda vez que fazemos esse tipo atribuição. Nosso problema está com o item 2, onde estamos tentando atribuir uma String a uma propriedade Number.

Para resolver essa situação eu criei a classe NumberInput que extende a classe TextInput do spark, e funciona com um wrapper para a propriedade text do TextInput, o source do novo componente é simples e fica assim:

Quando aplicamos o novo componente, o erro some do projeto e conseguimos compilar:

Abaixo segue o exemplo funcional:

Para fazer o download da biblioteca que contém o NumberInput, clique aqui.

2. Acessar o File Type ActionScript -> ActionScript Class e caso você utilize a configuração default, irá ver o seguinte template. Clique no botão editar a direita para iniciar a edição.

3. Vamos editar o template do ActionScript Class agora, colocando as seguintes informações:

@author é uma tag ASDoc, com isso garantimos que todas as novas classes tenham essa informação.

4. Agora iremos iniciar o mesmo processo mas com componentes MXML. Para isso iremos acessar o File Type MXML -> MXML Component. Clique no botão editar a direita para iniciar a edição.

5. Vamos editar o template do MXML Component com as seguintes informações:

Como poucas pessoas sabem no mxml temos 1 marcador para cometários e outro para ASDoc. A única diferença entre eles é apenas um ‘-’ e outra modificação que fiz foi remover o ${wizard_attributes}. Eu particularmente não gosto de ficar preenchendo o width/height no wizard da criação do novo component (imagem abaixo) e sempre tenho que apagar ambas as caixas quando crio um novo, com essa mudança não vai fazer diferença preencher as caixas ou deixá-las vazias.

6. Todas as novas classes ActionScript Class do seu projeto irão seguir o seguinte template

7. Todos novos MXML Component do seu projeto irão seguir o seguinte template

Agora que já sabem o básico sobre File Templates do Flash Builder, comecem a incrementar os seus próprios e, caso cheguem a uma solução, exporte e compartilhe com seus colegas de trabalho.

EU VOU!!!

Em abril teremos a segunda versão do Flash Camp Brasil, com certeza é o maior evento sobre a plataforma Flash ocorrido no Brasil, reunindo os maiores profissionais e especialistas do Brasil e do mundo especialmente para mostrar ao publico brasileiro as ultimas novidades da plataforma Flash, é um evento obrigatorio tanto para designers quanto desenvolvedores além de uma otima oportunidade de aumentar seu networking.
O evento acontecerá em macéio, e contaremos com palestrantes nacionais e internacionais, e muitos workshops para que voce possa aproveitar o maximo o que o evento tem para oferecer.
Entre os temas discutidos teremos:

• Anúncios inéditos trazidos por empregados e evangelistas da Adobe
• Flash em dispositivos móveis (AIR/BlackBerry/Android/iOS/Flex etc)
• Plataformas e App Stores disponíveis no mercado
• Novos métodos de geração de negócios e pagamentos
• Aplicações Flex no mundo corporativo, focadas em produtividade e ROI
• Adobe MAX 2010 Recap, novidades da maior conferência Adobe no mundo
• Fluxos de trabalho com a Flash Platform
• Molehill, o futuro do Flash Player focando em 3D para Games e Rich Internet Applications
• Flash na TV e em aparelhos multitouch
• A importância do design e User Experience (UX) em projetos interativos
• Apresentações de agências premiadas como Seagulls Fly (USA e São Paulo), Gringo (São Paulo), Adobe (USA e Brasil), Dedo US e University of California San Diego (UCSD)
• Tecnologias e novidades que facilitam a vida de designers e developers
• Plataformas de publicações como revistas e jornais em dispositivos móveis
• E-learning e transmissão de vídeo
• Estratégias de Social Media e uso de APIs públicas (Facebook, Linkedin, Twitter, Flickr, Google, PayPal, etc)

Não perca tempo e faça já sua inscrição para o Flash Camp Brasil
http://www.flashcampbrasil.com.br

Veja minha experiencia no primeiro Flash Camp Brasil