Quando se constroem aplicações web, é normalmente uma boa prática configurar-se o ambiente de desenvolvimento de forma a que seja o mais semelhante possível ao ambiente de produção.
Uma das configurações que se faz antes de se iniciar o desenvolvimento do projecto, é a criação de um virtual host cuja configuração seja o mais idêntica possível à configuração do servidor onde o projecto estiver alojado.

Entre outras configurações, a mais importante é a estrutura de directorias, que em desenvolvimento é diferente da estrutura em produção.

Regra geral, quando se trata de uma aplicação com backend e um backoffice nós costumamos organizar o nosso ambiente de desenvolvimento desta forma:

\projectos\projecto

\projectos\projecto\backend (backend, por exemplo em php)
\projectos\projecto\mm (imagens, e outros recursos multimédia)

Quando corremos a aplicação localmente, sem os virtual hosts, vamos obter algo como http://localhost/projecto/bin-debug/index.swf .

Para que a aplicação possa comunicar com o backend, o path para o gateway será por exemplo algo como ../../backend/gateway.php .

Para que a aplicação possa aceder aos recursos multimédia (imagens, etc) o caminho será algo como ../../mm/imagem1.jpg .

Estes caminhos não batem certo com os caminhos na versão de produção:

www.projecto.pt (binários da aplicação)
www.projecto.pt/backoffice (binários do backoffice)
www.projecto.pt/backend (backend, por exemplo em php)
www.projecto.pt/mm (imagens e recursos multimédia)

Vemos que na versão de produção a aplicação para aceder ao backend vai fazer o caminho backend/gateway.php – enquanto que na versão de desenvolvimento, fazia o caminho ../../backend/gateway.php . O mesmo se aplica para as restantes directorias.

Há muita gente que trabalha com a estrutura de directorias e caminhos do ambiente de desenvolvimento, e quando chega a altura de alojar o projecto, mudam os caminhos no source code (ou num ficheiro de configuração) e recompilam – má prática.

Solução: criar um virtual host

O Apache permite que se associe um ambiente com configurações específicas a um determinado domínio. Ou seja, se o Apache receber um pedido de acesso ao dominio www.projecto.dev , e houver um virtual host para esse dominio, podemos configurá-lo para devolver a nossa própria estrutura de directorias (e não só).

O que gostariamos era de escrever no browser www.projecto.dev , e ser-nos exposto o nosso projecto com a estrutura de directorias igual à estrutura que vamos obter no servidor.

Vamos começar por configurar o apache editando o ficheiro httpd.conf na directoria conf do apache. No final do ficheiro, basta adicionar as seguintes linhas:

NameVirtualHost 127.0.0.1
Include conf/vhosts/*.conf

A primeira linha permite que o apache possa associar os nomes dos domínios pedidos aos virtual hosts que vamos configurar (mais info aqui).

A segunda linha indica ao Apache para carregar e executar todos os ficheiros de configuração com a extensão .conf na directoria vhosts. Isto fará com que criar um novo virtual host seja algo como criar um novo ficheiro .conf na directoria vhosts.

Vamos agora à directoria vhosts, e vamos criar um ficheiro chamado projecto.conf .

Nesse ficheiro, vamos colocar o seguinte:

<VirtualHost 127.0.0.1:80>
DocumentRoot "D:\OsMeusProjectos\projecto\frontend\bin-debug"
ServerName www.projecto.dev
<Directory "D:\OsMeusProjectos\projecto\frontend\bin-debug">
Options Indexes FollowSymLinks Includes ExecCGI
AllowOverride All
Order allow,deny
Allow from all
</Directory>

Alias /backend "D:\OsMeusProjectos\projecto\backend"
Alias /backoffice "D:\OsMeusProjectos\projecto\backoffice\bin-debug"
Alias /mm "D:\OsMeusProjectos\projecto\mm"
</VirtualHost>

Isto vai indicar ao Apache que os pedidos recebidos na porta 80, máquina 127.0.0.1 relativos ao domínio www.projecto.dev irão ter a directoria bin-debug do frontend como a directoria de raíz do projecto. Os Aliases permitem que o Apache exponha o backend, backoffice e mm em directorias específicas, resultando assim num ambiente igual ao de produção.
Depois de feita a alteração acima, é preciso reiniciar o Apache.

Falta conseguirmos fazer com que pedidos para www.projecto.dev vão parar ao Apache. Para isso, vamos mexer no ficheiro "hosts" do Windows para forçarmos o redireccionamento de pedidos para www.projecto.dev para a nossa máquina local.
Basta para isso editar o ficheiro hosts (mais info no wikipedia), na directoria c:\windows\system32\drivers\etc . Recordo que no Windows Vista, será preciso abrir um editor de texto com permissões de administrador, e depois fazer o File > Open e procurar o ficheiro no disco – caso contrário não será possível editá-lo.

Neste ficheiro, bastará colocar o seguinte:

127.0.0.1 www.projecto.dev

A linha acima vai indicar o sistema operativo que todos os pedidos feitos para o domínio www.projecto.dev vão ser reencaminhados para 127.0.0.1 – a nossa máquina local. Como estamos a fazer os pedidos dentro de um web-browser, a porta por defeito será a 80. O resto é fácil de adivinhar: pedidos para a nossa máquina local na porta 80 vão ser entregues a quem? Ao nosso amigo Apache! Que ao receber um pedido destinado ao domínio www.projecto.dev, vai procurar o Virtual Host respectivo e expô-lo com a estrutura que definimos.

Obviamente, isto abre-nos as portas para fazer configurações mais radicais (i.e. configurar o Apache para que o Virtual Host seja igualzinho ao do servidor final).

Fizemos na Webfuel um projecto há uns meses para um dos principais criadores de joias nacionais. Um dos requisitos do cliente era que na secção de showroom, cada joia pudesse ser apresentada dentro de uma ferramenta de zoom que permitisse ver a joia em detalhe – implicando que as fotos das joias tivessem resoluções superiores a 700×700 pixeis. Outro dos requisitos, era que as imagens das joias não tivessem fundo para que pudessem encaixar correctamente no layout do site – implicando que teria que ser escolhido um formato que suportasse transparência, neste caso PNG. Para terminar, era imperativo que o cliente, sem quaiquer conhecimentos de informática, pudesse adicionar e actualizar as fotos das joias através do backoffice – implicando que cada foto fosse um PNG colocado no servidor pelo cliente através das funcionalidades do backoffice.

Estas pré-condições implicaram o recurso ao formato PNG – o único que permitiria resolver o problema, visto a norma JPEG2000 não ser suportada pelo Flash Player. Porém, adoptar o formato PNG para as fotos das joias com as dimensões acima referidas resultou em ficheiros de cerca de 500KB. Isto, num site com cerca de 200 a 300 jóias, com várias fotos cada.

Depois do deployment do site constatou-se o esperado: em ligações rápidas, os 500KB de cada foto não representavam grandes problems, mas em ligações lentas podia ser desesperante esperar de 10 a 20 segundos para a foto carregar. E com o disseminar recente das ligações 3,5G (kangurus, vodafone e tmn connect box, etc), tornou-se problemático pelo que tivemos que procurar por uma solução.

Encontrámos uma extensão chamada PNG2SWF pertencente ao pacote SWFTools que permitia converter um PNG para um SWF. Como é sabido, um PNG embebido em SWF pode levar compressão sendo mantida a transparência, pelo que decidimos fazer algumas experiências. Após alguns testes, tivemos resultados impressionantes: imagens de 500 Kb passaram para 60 Kb sem serem perdidos os canais alpha. Exactamente o que precisávamos!

O problema que surgiu de seguida consistia em saber como integrar o PNG2SWF com o site / backoffice sem afectar a experiência do utilizador. Era importante que o cliente continuasse a utilizar o backoffice como sempre, sem trabalho adicional.

Fizemos então um script simples, que vos ofereço adiante, e que consiste num género de proxy para carregar PNGs, só que devolve o PNG convertido para SWF, e escalado para dimensões arbitrárias escolhidas pelo programador.

O download do script pode ser feito aqui: pngoptimize . O source code pode ser visto abaixo:

<?php

    // 31-10-2008
    // pngOptimize.php by João Saleiro - Webfuel ( joao.saleiro@webfuel.pt)
    // Todo:
    // - receive quality from $_GET vars
    // - set default values for quality, w and h

    $image = $_GET['url'];
    $w = $_GET['w'];
    $h = $_GET['h'];

    $date = filemtime($image);

    // Generate SWF filename
    $swf = $image . $w . $h .'_'. $date .'.swf';

    // Generate SWF if it doesn't exist
    if (!file_exists($swf))
    {
        // Calculate dimensions
        list($width, $height) = getimagesize($image);

        $proportion = 1;
        if ($width > $height)
            $proportion = $w/$width;
        else
            $proportion = $h/$height;

        // Load image and preserver transparency
        $im = @imageCreateFromPNG ($image);
        imagealphablending($im, false);
        imageinterlace ( $im, 0);
        imagesavealpha($im, true);

        // Create new Image
        $im_dest = imagecreatetruecolor ($width*$proportion,  $height*$proportion);

        // Set transparency
        $background = imagecolortransparent($im);
        imagecolortransparent($im_dest, $background);
        imagealphablending($im_dest, false);
        imagesavealpha($im_dest, true);

        // Resize old image to new image
        imagecopyresampled($im_dest, $im, 0, 0, 0, 0, $width*$proportion, $height*$proportion, $width, $height);

        // Save new image
        $tempName=$image.'temp.png';
        imagepng($im_dest, $tempName);

        // Clean memory
        imagedestroy($im);
        imagedestroy($im_dest);    

        // Convert new image to SWF
        shell_exec("./png2swf -j 85 -o $swf $tempName");

        // Remove temp file
        unlink($tempName);
    }

    // If we get here, and there's no file, we don't return nothing
    if (!file_exists($swf))
        exit(0);

    // Return generated SWF
    header("Content-type: application/x-shockwave-flash");
    $fp = fopen($swf,"rb");
    fpassthru($fp);
    fclose($fp);
?>

O algoritmo é relativamente simples:

1. O script recebe por GET os parâmetros: url, w e h, que correspondem ao endereço relativo do PNG, e as dimensões que queremos para o nosso SWF resultante;
2. O script vai então gerar um nome de ficheiro único para aquele url, com aquelas dimensões, e para a data do PNG (i.e. se o PNG for actualizado pelo cliente o script detecta que há um PNG novo, o que implica gerar um novo SWF com novo nome);
3. É verificado se já existe algum SWF com aquele nome único (i.e. uma versão em cache daquele PNG já convertido para SWF com aquelas dimensões). Se existir, o SWF é aberto e lido, e feito um fpassthru do ficheiro (i.e. é devolvido o conteúdo do ficheiro SWF), depois de definido o header application/x-shockwave-flash para que o Flash possa interpretar o resultado do ficheiro PHP como sendo um SWF;
4. Se não existir nenhum SWF, o script vai abrir o PNG referido no URL, e criar um novo PNG temporário com as dimensões referidas, mantendo a transparência;
5. É então feita a conversão desse PNG temporário para SWF através de um shell_exec que executa o png2swf com os parâmetros necessários para a conversão, sendo gerado um SWF com o nome de ficheiro referido acima, e devolvido com o fpassthru.

Para utilizar este script é necessário:

• Colocar no servidor, na mesma directoria do pngConvert.php, o png2swf (linux) ou png2swf.exe (windows);
• Permissões de execução do png2swf nessa directoria;
• Permissões do php para a chamada de comandos externos (shell_exec);
• Permissões de escrita nas directorias onde estão os ficheiros PNG para serem lá colocados os ficheiros SWF;

Do lado do cliente, o código necessário para carregar um PNG convertido para SWF através do pngConvert é:

• MXML:

<mx:Image source="pngConvert.php?url=imagem.png&w=100&h=100"/>

• Actionscript 3 (i.e. Flash)

var l:Loader=new Loader();

l.load(new URLRequest('pngConvert.php?url=imagem.png&w=100&h=100'));

addChild(l);

O script ainda pode levar algumas melhorias, nomeadamente:

• a qualidade da imagem também ser passada por GET;
• se os parâmetros w e h não estiverem definidos, o SWF gerado é da mesma dimensão que o PNG original.

Não implementei essas melhorias porque não precisei na altura, mas se alguém quiser melhorar, é bem vindo – publicarei depois aqui a versão melhorada, com devidos créditos.

Espero que esta informação e script vos sejam úteis. O script pode ser utilizado livremente e só pedimos que seja colocado um comentário neste post com o endereço do site onde o estão a usar, para alegrarem o nosso dia.

A Adobe publicou ontem uma imagem muito interessante e elucidativa para representar o ecosistema da Flash Platform. Na imagem é possível ver o universo das ferramentas Adobe, e a forma como se interligam.

À esquerda, a azul claro, temos as ferramentas de design: After Effects, Adobe Illustrator, Fireworks e Photoshop. Com estas ferramentas os designers podem criar o aspecto gráfico das aplicações / sites / experiências / etc, sendo este exportado num novo formato, o FXG. O FXG é um novo formato da Adobe baseado em XML para representar elementos gráficos, e que é compatível com o universo que circunda a plataforma Flash.

A azul escuro temos as aplicações de desenvolvimento: o Flash IDE, Flash Catalyst (anteriormente conhecido por Thermo), e o Flex Builder. O Flash IDE e o Flex Builder são os nossos já velhos conhecidos, sendo o primeiro mais virado para Interaction Designers que procuram um IDE visual, e o segundo para developers que procuram um IDE virado para código. O Flash Catalyst é uma ferramenta que ficará no meio, entre o Flash e o Flex Builder que permitirá a Interaction Designers utilizar um ambiente gráfico e intuitivo para importar layouts feitos nas ferramentas de design, e convertê-los através de alguns cliques para aplicações, podendo ser adicionada interactividade. O resultado o Flash Catalyst é MXML (bem formado, segundo dizem) que depois é entregue aos developers para implementarem toda a parte dura do código. Segundo se diz, o Flash Catalyst pode também carregar MXML já alterado pelos developers (corrijam-me se estiver enganado), pelo que permitirá que ambas as equipas – developers e designers – possam trabalhar ao mesmo tempo, recorrendo a um source control. O Flash Catalyst está ainda a um ano de ser lançado em versão final, pelo que durante este período serão certamente disponibilizadas versões beta e de preview.

A cinzento, em cima, temos o Flex SDK, a framework de eleição para desenvolvimento de RIAs. É composta por um conjunto de componentes, e ferramentas que assentam em Actionscript 3, para desenvolvimento rápido de aplicações. O Flex SDK está actualmente na versão 3, mas a versão que se segue (nome de código: Gumbo) vai trazer novidades absolutamente estontantes. Sendo open-source, é possível acompanhar o desenvolvimento do Gumbo, e inclusivé, fazer já aplicações com a actual versão. As milestones do Gumbo são:

• lançamento do MAX preview agora durante o MAX;
• versões Beta 1 e Beta 2 na primeira metade de 2009 (aposto em Fevereiro e Maio);
• versão final na segunda metade de 2009.

As ferramentas acima “não fazem mais” que gerar ficheiros SWF que são depois interpretados e executados nos devidos runtimes: o Flash Player, que corre dentro do browser, e com limitações de acesso à máquina do utilizador (obviamente por motivos de segurança), e o Adobe Air, que permite que os SWFs possam ser instalados nos computadores dos utilizadores e correr como aplicações desktop, com acesso à maquina do utilizador como qualquer outra aplicação (i.e. leitura do disco, clipboard, etc). O Flash Player está neste momento na versão 10 que introduz uma panóplia de funcionalidades fantásticas: suporte nativo a 3D, FileReference local, suporte a filtros avançados (Pixel Bender), suporte avançado a texto, melhor performance com suporte a aceleração pela placa gráfica, etc.

De referir que os runtimes acima são compatíveis com os principais sistemas operativos, nomeadamente Mac, Windows e Linux – e a grande novidades do Max: graças ao Open Screen project temos também o Flash Player 10 em Symbian, Windows Mobile, Wii, Playstation, etc.

As aplicações (SWFs) que assentam sobre os runtimes acima serão fat clients descarregados para as máquinas dos utilizadores (pelo browser, ou instalados com Adobe Air), e que poderão posteriormente comunicar com um servidor para trocar dados. Essa comunicação pode assentar em diversos protocolos e formatos, tais como simples texto, XML, SOAP (web-services), JSON, e AMF – o formato de dados em que assenta o Flash Remoting. Estes formatos podem ser trocados sobre HTTP ou HTTPs, Sockets, RTMP, entre outros.

Esta panóplia de formatos de comunicação permitem comunicar com quase todas as tecnologias server-side existentes no mercado, pelo que aplicações feitas em Flash são facilmente integráveis com plataformas existentes, sejam elas Adobe ou de terceiros. Da Adobe, temos os servidores especificamente criados para Flash: BlazeDS e Flash Media Server que introduzem funcionalidades de Data e Multimedia Streaming, entre outras. Depois temos os servidores ColdFusion e LiveCycle ES, de onde a minha funcionalidade favorita deste último é de longe o facto dos servidores poderem tomar a iniciativa de contactar os clientes e empurrar dados (i.e. dados dos clientes sincronizados automaticamente com o servidor). Apesar da Adobe fornecer as suas próprias soluções server-side, como dito acima aplicações Flash podem ser facilmente integradas com outras soluções de backend de entidades terceiras, como, PHP, JAVA, .NET, etc, desde que implementem algum dos protolocos de comunicação acima referidos. Como exemplos de plataformas, temos BEA, SAP, salesforce.com, WebSphere, Zend, etc.

Vendo esta imagem, é inevitável sentir orgulho de ter acreditado e escolhido um dia o caminho da plataforma Flash. Aquilo que começou um dia como uma ferramenta para adicionar animações a páginas Web, é hoje em dia a mais poderosa plataforma para criar aplicações distribuídas e interactivas. As nossas amigas RIAs.

No último evento do Adobe User Group, Nelson Batista fez uma pequena introdução ao Papervision3D onde explicou a composição do framework, como utilizar assim como certos erros a evitar.

Como parte dos meus estudos para a Certificação Flex 3, estou a rever alguns pontos em que me sinto menos à vontade dentro do maravilhoso mundo do Flex. Vou começar por um ponto que ainda hoje reserva bastantes dificuldades de compreensão. Falo do MVC – Model, View, Controller.

O MVC é um padrão quer de desenho quer de arquitectura usando na construção de software. O uso deste padrão é muito vasto, e entende-se como o tratamento separado da lógica de programação e a interface grafica do proprio software que resulta numa enorme versatilidade da aplicação que torna muito mais facil modificar o aspecto visual da aplicação ou o código sem criar dependencias/afectação entre eles lidando facilmente com a comunicação entre utilizador, interface gráfica e o código da nossa aplicação.

Entendendo as siglas;

• Model – Representa a informação / dados da aplicação e as “regras/definições” para manipular / trabalhar com esses mesmos dados da aplicação. No flex, geralmente class pessoais ou classes de serviços para lidar com um backend.
• View – Representa os elementos gráficos da nossa aplicação, como inputText, datagrid, textArea, no flex engloba states, viewstacks, em resumo, todos os componentes gráficos.
• Controller – Representa o tipo de controlo/detalhes que envolvem a comunicação com o Model (Dados e definições) e o View (Interfaces gráficas) estes detalhes resultam da lógica de comunicação entre o Model e o View e normalmente representam também a interacção com o utilizador.

Este padrão MVC foi adaptado por centenas de frameworks, e o Flex não escapou à adaptação sendo que o principal objectivo de uso deste MVC no Flex é a simplicidade e re-utilização do código criando componentes bem definidos que permitem a obtenção de uma enorme versatilidade de todos os eles, bem como uma fácil cominicação entre os mesmo componentes, sem falar numa optimização do desempenho da nossa aplicação.

Ao criarmos um aplicação sem nos preocuparmos com este padrão teremos uma agradavel supresa no final de a termos terminado. O próprio Flex / Framework já está baseada nesta arquitectura e possui mesmo os seu proprio padrão MVC definido, como os componentes que definem a interface do utilizador, os modelos de apresentação de dados e os componentes responsaveis pelo controlo de dados como interacções com linguagens back-end.

Tentar entender este processo no ambito do flex pode ser muito complicado, mas vamos colocar um caso lógico que explica muitas das operações do flex:

Onde estruturamos devidamente os elementos e acções deste modelo:

Model:

• Usando action script, definindo como estrutura de class.
• Geralmente são usadas varias classes para simplificação de objectivos de cada uma que englobam:
• — Classes de dados nativas
• — Serviços de comunicação com back-end
• — No AIR, classes para lidar com chamadas como o SQLite

View :

• Todas as views são componentes gráficos do flex
• Tem como principal objectivo lidar com o layout da aplicação e disparar eventos para o controller
• Não acedem a dados directamente, apenas usam dados de eventos, dataProviders ou propriedades publicas / databinds
• São geralmente componentes escritos em MXML

Controller :

• Pode existir mais que um, embora apenas seja necessário em aplicações muito complexas.
• É usado como ponte entre o View e o Model visto que estes 2 não podem comunicar entre si directamente. Algumas propriedades / funções :
• — Definir dataproviders
• — Chamadas para o Model
• — Lidar com eventos do View
• — Alternar entre views
• Não são necessáriamente Action Script, no flex os arquivos MXML podem ser elementos “Controladores”

O Padrão MVC não se trata de um programa, formula ou função, trata-se sim de uma forma de organização de código permitindo esta “triologia” de funcionamento; criando uma class controlador que recebe/lida com dados de um conjunto de classes (model) e que faz a devida actualização da nossa interface grafica/componentes (view).

Claro que esta explicação pode ser mal entendida e perdoem-me os experts no padrão MVC, mas basicamente é isto que é feito claro que com alguns pontos e detalhes como vimos em cima.

Este tipo de implementações têm varias variantes, podendo nós, devidamente estruturado, criar um padrão MVC para estruturar a nossa aplicação, embora a Adobe disponibilize o Cairngorm que simplifica muito a aprendizagem pincipalmente com exemplos de muitos sites. A sua instalação é muito simples e o seu uso e aprendizagem também. Uma grande referencia em Cairngorm é o blog o David Tucker:

http://www.davidtucker.net/category/cairngorm/

Façam download dos videos e exemplos e facilmente verão do que falo.

Bem, na estrutura do exame Flex 3 este é um dos pontos: “List and describe de differences between model, view and controller in a Flex application”, que nos pede para explicar as diferenças apontadas em cima.

Bem, por agora é tudo… fiquem com alguns pontos de referencia do meu estudo sobre MVC.

http://cristobal.baray.com/indiana/projects/mvc.html (recomendo vivamente)

http://www.wonderhowto.com

http://livedocs.adobe.com/

http://www.iteratif.fr/blog/

Abraço e pelo menos espero ter esclarecido alguém, e já agora, alguém com uma opinião ??

Post originalmente colocado em: http://www.msdevstudio.com