Twitter!

Esta foi a 7a edição da Adobe Max que pude acompanhar pessoalmente. Posso dizer com propriedade que está foi a Max que menos vi novidades, mas talvez foi a mais importante que tive a oportunidade de participar. Antigamente ficava colocando novidades técnicas. Agora pretendo fazer você pensar.

No ano passado estava muito forte a velha estória de Flash vs Html 5 e, de certa maneira, isso ainda persiste na mente de muitas pessoas. Ficou muito claro que para a Adobe isso não é um problema. Não podemos esquecer que na essência, a Adobe é uma empresa que desenvolve ferramentas para facilitar a vida de Designer, Arquitetos de Informação, Developers etc. A Adobe nunca foi contra o Html 5, inclusive ela sempre fez parte do W3C participando da definição dos padrões do Html 5. Vi progressos de ferramentas como o Adobe Edge e integrações do Dreamweaver com JQuery e PhoneGap muito interessantes. Alias a Adobe comprou a PhoneGap como vocês já sabem.

Mas e o flash? Confesso que no meio da conferência coloquei no twitter: “Acho que pela primeira vez o flash vai morrer”. Disse isso vendo as maravilhas que a Adobe estava mostrando com CSS e Html 5 e algumas sugestões que eles estavam fazendo para o W3C. Depois analisei com mais calma e acho que me precipitei. O flash tem um longo caminho pela frente, mas acho que ele vai ocupar espaços específicos. Vejo o flash usado em totens, aplicações com consumo grande dados, que abusem de processamento (flash agora usa GPU), aplicações internas específicas, games, 3D etc. Veja esta experiência: http://www.nissan-stagejuk3d.com/. Isso ainda vai ser flash por um bom tempo.

Na conferência vimos os melhores games rodando em Flash. Esse é um caminho sem volta e quem sabe no futuro você não precise mais de seu PS3 ou Xbox e faça isso na sua próxima TV com flash ou no seu próprio micro. Também vimos a Adobe muito bem posicionada para o desenvolvimento de apps para dispositivos móveis. Um código fonte para iOS e Android, só a Adobe consegue isso hoje. Até conseguimos fazer apps com html 5 e CSS, mas os apps desenvolvidos com as ferramentas da Adobe nos dão uma performance melhor. Além de tudo, desenvolvimento para desktop com AIR também é imbatível e agora com Native Extensions, o céu é o limite.

Ficou claro que aplicações tradicionais com formulários e transações serão em Html 5. Eu já fui em vários clientes e pergunta era sempre a mesma: “Funciona no iPad?”. Sabemos que o certo seria fazer um app específico e que os tablets e dispositivos móveis requerem iterações específicas. Mas nossos clientes e usuários querem acessar suas aplicação do seu browser de qualquer lugar e de qualquer dispositivo.

Então é isso? E a compatibilidade do browser? E a facilidade do SDK do Flex? E a carga de testes vai aumentar? A resposta é que esse é um caminho sem volta. E o melhor de tudo é que isso é uma grande oportunidade para todos. Vamos sim enfrentar o velho problema de compatibilidade de browsers, fabricantes e desenvolvedores de browsers querendo cada um “impor” o seu padrão. Mas quando grandes como Microsoft, Apple, Google, Facebook e Adobe dizem que este é o caminho, é melhor refletirmos sobre isso. Até grandes desenvolvedores da comunidade Flex falam sobre isso. Vi uma palestra do Grant Skinner sobre um jogo que ele fez em html 5 usando canvas.

Na DClick nós sempre falamos que a tecnologia é meio. O mais importante é a solução e a experiência do usuário. Se para o usuário não acessar sua aplicação de um tablet ou um celular é um problema, isso é um problema de experiência. Somos muito conhecidos pelo uso do Flex e Flash e temos muito orgulho disso, mas Html 5, JQuery, CSS etc, também são realidade para nós. Novamente, tecnologia é meio.

Para mim, não existe tecnologia “matadora” para tudo. Cada problema tem a melhor solução. Cada tecnologia tem seus prós e contras. Não perca o seu tempo “pixando” uma ou outra tecnologia. Veja o que cada uma pode trazer de benefício para você, seus aplicativos e seus clientes. Estude. E o mais importante, Seja feliz!

No Flex, podemos criar um panel que possui botões genéricos, como Salvar e Remover, que disparam eventos e podem ser usados para criar formulários com mais eficiência.

Veja o vídeo:

Neste screencast, falarei um pouco sobre o Spark Form, componente disponível no Flex 4.5 que está previsto ficar disponível ao publico no início do próximo mês.

Você vai ver como podemos criar formulários mais elegantes usando o novo componente da arquitetura Spark.

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?

Tenho utilizado muito o iPad para me atualizar após o dia de trabalho. Muitas vezes acabo me deparando com um ou outro serviço interessante e que exige cadastro antes de desfrutar do conteúdo. Hoje mesmo aconteceu duas vezes. O primeiro problema é preencher cadastros que solicitam, além do trivial (nome, e-mail, usuário e senhas); endereço [...]

* Alta disponibilidade
* Segurança abrangente
* Gerenciamento simplificado de TI

 O BPOS é composto dos seguintes serviços online:

Twitter: @atsh2

Está procurando alguns tutoriais de Adobe Flex? O blog Design Your Way separou 45 tutoriais muito bacanas para Adobe Flex, eu separei os que eu achei mais interessantes e relevantes.

Aproveite e bons estudos!

01º Flex MP3 Player

02º XML Básico com Flex 3

03º Criando uma galeria 3D do Flickr com Flex e Awaya3D

04º Usando a classe TextRange

05º Construindo um ItemRenderer para TileList

06º Rotacionando a ViewStack em forma de Cubo

07º Drag Drop simples no Flex

08º Cursor customizado no Flex

09º Como fazer gráficos no Flex

10º Visualizador de imagens em miniaturas no Flex

11º Jogo da Velha em Flex com Degrafa

12º Formulários no Flex

13º Sistema de Login em Flex com PHP

14º Pegando informações de músicas do WebService da Amazon com o Adobe Flex

15º Instalando e usando o Google Maps no Flex

16º Galeria de imagens com o componente Accordion e XML no Flex

17º Interação entre Flex e Javascript

18º Múltiplos uploads com JQuery e Flex ou Flash

19º Desenvolvendo janelas em Flex ou Flash para o Adobe Photoshop

20º Criando um cliente Digg em Flex

21º Introdução ao Data Binding

22º Data Grid com XML

23º Usando Flex, PHP e Json para modificar dados no MySQL

24º Trabalhando com o Debugger no Adobe Flex Builder

25º Criando um relógio de contagem regressiva em Flex

26º Transmitindo dados entre Flex e PHP usando Json

27º Criando um leitor de Feeds (RSS) em Flex

28º Como criar um gráfico de Bolhas em Flex

29º Usando Item Renderes

30º Criando um formulário de email em Flex com PHP

31º Criando grandes listas dinâmicas em Flex

32º Encodificador assincrono de JPEG

33º Criando seu jogo de aventura no Adobe Flex

34º Mudando o identificador de seleção de uma Lista no Flex

35º Criando um player customizado do You Tube em Adobe Flex

36º Criando uma lista de contatos usando Flex e XML

37º Criando um album de fotos do Facebook em Flex

38º Modificando o estilo da linha selecionada na Data Grid

Se você ainda não leu CRUD com Flex e Zend_AMF – Parte 1, leia agora

Agora que nossa conexão foi estabelecida, podemos começar a adicionar registros. Esta é a nossa primeira tarefa, e para isso precisamos criar um formulário de entrada de dados. Geralmente os formulários de entrada de dados são feitos em uma popup, e vamos seguir esta regra, ok?

Crie um novo MXML Component, chamado: PessoaForm.mxml, conforme a imagem a seguir:

O código inicial deste componente está a seguir:

<?xml version="1.0" encoding="utf-8"?>
<s:TitleWindow xmlns:fx="http://ns.adobe.com/mxml/2009"
		   xmlns:s="library://ns.adobe.com/flex/spark"
		   xmlns:mx="library://ns.adobe.com/flex/mx"
		   width="300" height="150"
		   title="Pessoa"
		   close="{PopUpManager.removePopUp(this)}"
		   >
<s:layout>
	<s:VerticalLayout/>
</s:layout>

<fx:Declarations>
	<!-- Place non-visual elements
	(e.g., services, value objects) here -->
</fx:Declarations>

<fx:Script>
	<![CDATA[
		import mx.managers.PopUpManager;

		import spark.components.PopUpAnchor;
	]]>
</fx:Script>

<mx:Form width="100%" height="100%">
	<mx:FormItem label="Nome:" width="100%">
		<s:TextInput id="nome" width="100%"/>
	</mx:FormItem>
	<mx:FormItem label="Email:" width="100%">
		<s:TextInput id="email" width="100%"/>
	</mx:FormItem>
</mx:Form>

<s:controlBarContent>
	<s:HGroup horizontalAlign="right" width="100%">
		<s:Button id="btnOk" label="OK"/>
		<s:Button id="btnCancelar"
				  label="Cancelar"
				  click="{PopUpManager.removePopUp(this)}"/>
	</s:HGroup>
</s:controlBarContent>

</s:TitleWindow>

Neste código criamos um form com dois campos, mais os botões ok e cancelar. Até aqui nada de mais. O botão cancelar remove o popup, pois este TitleWindow será um popup.

Voltando à aplicação principal, temos que criar o botão que irá abrir este TitleWindow. Alterando o código da aplicação (Parte 1), temos:

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="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">

<fx:Declarations>
<mx:RemoteObject id="RemotePessoas"
				 destination="zend"
				 source="Pessoas">

	<mx:method name="TesteConexao"
			   result="OnTestConexaoOk(event)"/>

</mx:RemoteObject>
</fx:Declarations>

<fx:Script>
	<![CDATA[
	import forms.PessoaForm;

	import mx.controls.Alert;
	import mx.managers.PopUpManager;
	import mx.rpc.events.ResultEvent;
	public function OnTestConexaoOk(event:ResultEvent):void
	{
		Alert.show(event.result.toString());
	}
	]]>
</fx:Script>	

<s:Button label="Adicionar Pessoa" top="10" left="10">
<s:click>
	<![CDATA[
		var p:PessoaForm = new PessoaForm();
		PopUpManager.addPopUp(p,this,true);
		PopUpManager.centerPopUp(p);
	]]>
</s:click>
</s:Button>

</s:Application>

O botão “Adicionar Pessoa” da aplicação principal abre uma popup, exibindo o formulário abaixo:

Agora podemos voltar ao código do formulário e adicionar a funcionalidade de “adicionar pessoa”. Para isso usamos o RemoteObject. O código do arquivo PessoaForm.mxml fica assim:

...
<fx:Declarations>

 <mx:RemoteObject id="pessoaRemote"
		 destination="zend"
		 source="Pessoas"
		 showBusyCursor="true"
		 >

	<mx:method name="Inserir"
	   result="OnInserir(event)"
	   fault="OnFault(event)"
	   />

  </mx:RemoteObject>

</fx:Declarations>

...

<fx:Script>
<![CDATA[
import mx.controls.Alert;
import mx.managers.PopUpManager;
import mx.rpc.events.FaultEvent;
import mx.rpc.events.ResultEvent;

import spark.components.PopUpAnchor;

protected function OnInserir(event:ResultEvent):void
{
	PopUpManager.removePopUp(this);
}

protected function OnFault(event:FaultEvent):void
{
	Alert.show(event.message.toString(), "ERROR");
}

]]>
</fx:Script>

....

<s:Button id="btnOk" label="OK">
	<s:click>
	<![CDATA[
		pessoaRemote.Inserir(nome.text,email.text);
	]]<
	</s:click>
</s:Button>

As mudanças no código são relativas ao RemoteObject, que possui o método inserir, disparado pelo click do botão. O método inserir deve ser criado no arquivo pessoas.php, conforme o código a seguir:

<?php
class Pessoas
{
	var $db;

	function __construct()
	{
		$this->db = new Zend_Db_Adapter_Pdo_Mysql(array(
		'host'     => '127.0.0.1',
		'username' => 'root',
		'password' => '',
		'dbname'   => 'flexcrud'
		));
	}

	function TesteConexao()
	{
		return "OK";
	}

	function Inserir($nome,$email)
	{
		$data = array('nome'=>$nome,'email'=>$email);
		$this->db->insert('pessoas',$data);
		return $this->db->lastInsertId();
	}

}

Neste momento já podemos testar a aplicação. Caso dê algum erro, verifique o log de erros em c:wamplogsapache_error.log. Mas olhando o código do arquivo pessoas.php, podemos notar que ele tem um problema. Os parâmetros de conexão estão dentro da classe pessoas. Fiz isso de propósito, para mostrar que temos que ter uma visão crítica do nosso código, sempre que possível. Já imaginou termos 10 classes e cada uma delas tem as configurações do banco de dados? E se estas configurações mudarem?? Precisaremos alterar as 10 classes.. (eu acho que isso da justa causa hehe).

Para resolver o problema, podemos usar um pouco de orientação a objetos. Vamos criar uma classe chamada “Base”, que contém essa configuração, e fazer a classe Pessoas herdar de Base. Veja:

base.php:

<?php
class Base
{
	var $db;

	function __construct()
	{
		$this->db = new Zend_Db_Adapter_Pdo_Mysql(array(
		'host'     => '127.0.0.1',
		'username' => 'root',
		'password' => '',
		'dbname'   => 'flexcrud'
		));
	}
}

Agora a classe Pessoas fica assim:

<?php
include("base.php");

class Pessoas extends Base
{
	function __construct()
	{
		parent::__construct();
	}

	function TesteConexao()
	{
		return "OK";
	}

	function Inserir($nome,$email)
	{
		$data = array('nome'=>$nome,'email'=>$email);
		$this->db->insert('pessoas',$data);
		return $this->db->lastInsertId();
	}

}

Desta forma, conseguimos usar a variável $this->db em qualquer classe que herde da classe Base. No próximo artigo da série, iremos criar um datagrid para ver os dados que estão sendo inseridos. Aguardem!!