BlogCFC e “fully qualified names”

No blog da DClick estamos utilizando o sistemas de blog BlogCFC, escrito em ColdFusion por Raymond Camden, programador ColdFusion provavelmente bem conhecido do pessoal – ele mantém alguns projetos interessantes, como a lista CFCDev, CFLib e afins.

A idéia de utilizar o BlogCFC foi que justamente ele era em ColdFusion, de modo que seria fácil customizá-lo e utilizarmos em nosso servidor de hospedagem (que já tinha o CF instalado). Um das primeiras coisas que notei quando baixei o sistema de blog foi a grande quantidade de funções createObject() em objetos Java, e o nosso servidor de hospedagem usa sandbox security e por razões óbvias, bloqueia o uso de objetos Java no servidor, algo que aprovo e sempre sugerimos aqui no blog.

Leia o resto deste post »


Flex 1.5 no ColdFusion: cfchart, headless e múltiplas configurações da JVM

Assim como o ColdFusion, o Flex 1.5 também é uma aplicação Java, e digamos que você está desenvolvendo um projeto com ambas as tecnologias, normalmente iniciariamos duas instâncias – o ColdFusion standalone e o Flex standalone, ou a instância deles em um deploy num application server como o JRun ou TomCat. Mas o mundo Java é bem mais extensível do que isso e é possíval instalar as duas aplicações (ColdFusion e Flex) sob a mesma instância, iniciando portanto as duas ao mesmo tempo. Rodando as duas sob a mesma instância, sob os mesmos parâmetros de JVM, etc. A Macromedia disponibilizou um technote, há muito tempo atrás, de como instalar o Flex 1.5 no ColdFusion.

Porém, infelizmente isso pode trazer um notório problema que enfretei há muito tempo, no meio do ano passado (sim, esse é um post bem atrasado, mas que ainda sim pode servir de referência). Se seu application server estiver rodando em um servidor headless, isto é, sem monitor, sem placa e capacidade gráfica, o Flex 1.5, na instalação padrão não funciona, pois ele usa a API do Java AWT (Abstract Window Toolkit) para implementar tratamentos com gráficos e afins, e tenta usar processamento de hardware para tal. Como o servidor é headless, não há hardware para responder estas requisições. Em um caso que passei, o servidor era um Linux acessado remotamente por SSH – um verdadeiro “headless server”.

Felizmente há uma solução bem simples e trivial para isso, e a Macromedia (na época) disponibilizou um technote para servidores headless: adicionar o argumento -Djava.awt.headless=true na JVM, para que as instruções do AWT sejam executadas por software. Notem que neste technote, há uma passagem que diz: “Somente configure para headless se sua máquina realmente não tiver placa gráfica, caso contrário a tag cfchart do ColdFusion pode dar erros”.

No meu caso o ColdFusion e o Flex realmente estavam sob a mesma instância, mas o CF só provia as camada de negócios, e não gerava gráficos. Contudo, as outras instâncias do mesmo servidor (todas as instâncias sob o JRun 4) geravam gráficos com cfchart, e o JRun, por padrão, compartilha os parâmetros de inicialização da JVM, de modo que o parâmetro headless seria aplicado também às outras instâncias, inclusive as que tinham apenas o ColdFusion instalado. Mas o servidor era mesmo um headless, então não havia o que temer. Supostamente…

Mas todos os gráficos das outras instâncias do ColdFusion (criados com a tag cfchart) pararam de funcionar após o acréscimo do parâmetro do headless, parâmetro esse necessário para que o Flex instalado sob o mesmo JRun funcionasse!

Em um outro technote da Macromedia, fica claro que a tag cfchart não funciona se você utilizar o argument de headless na JVM (veja um outro technote sobre cfchart, headless e contas de domínio no Windows aqui). Mas oras.. eu precisava do parâmetro de headless para iniciar o Flex, mas não podia utilizá-lo se não os gráficos do ColdFusion paravam de funcionar!

Situaçlão delicada… Posto isso, algumas outras soluções eram possíveis. (1) Instalar uma placa gráfica no servidor, (2) ou rodar as instâncias com parâmetros de JVM diferenciados – algo que o JRun 4 não permite por sua interface administrativa (mas que felizmente se preocuparam em adicionar essa funcionalidade no JRun 4.5 “Cheetah”, em beta).

Então a primeira coisa que passou no momento foi instalar outro JRun, um com as instâncias do Flex 1.5 com ColdFusion, com o parâmetro headless na JVM, e outro JRun com as instâncias do ColdFusion, em que estes precisariam gerar gráficos via cfchart. Isso até descobrir que no JRun 4 é possível sim iniciar as instâncias com parâmetros de JVM separados (inclusive está no Release Notes).

Enfim, essa situação tende a não ser mais vista (já nem era tanto, já que é uma situação específica) com o advento do Flex 2 e a geração local (na máquina do desenvolvedor) dos arquivos, mas ficam por aqui as dicas (e o “causo”).


Novidades sobre o lançamento e preço do Flex 2

Recentemente vi uma mensagem na lista FlexCoders sobre um possível lançamento do Flex 2 em 28 de Junho, o que deu mais peso há um outro rumor que eu já havia escutado, sobre o lançamento do Flex 2 ainda nesse mês. Assim, o ColdFusion 7.0.2 (Mystic) deve ser lançado também nessa data – ou bem próximo.

E junto na mensagem foram divulgados os preços dos produtos. A Adobe já havia dito que o Builder custaria menos de 1000 dólares, mas eu sinceramente não imaginava que seria metade disso!

Flex Builder 2: USD$ 499, USD$ 749 com os componentes de gráfico;
Flex Data Services: USD$ 6.000 (100 usuários), USD$ 20.000 (Enterprise);
Chart Components: USD$ 299.

Vale lembrar que o Flex 2 SDK (conjunto de componentes e o compilador – que permite gerar o programa em SWF a partir dos códigos fonte) será gratuíto, assim como uma versão reduzida do Flex Data Services, a versão Express, bem limitada quanto ao número de aplicações.

As informações sobre o preço ainda não foram confirmadas pelo pessoal da Adobe, embora a informação tenha sido dado durante uma apresentação da própria. A mensagem na lista FlexCoders com os preços pode ser vista aqui.


Pela enésima vez.. o Flex 2 é gratuíto!

Ben Forta dá “uma bronca” no pessoal que está reclamando do preço do Flex 2.

Em primeiro lugar, e isso é uma constatação pessoal, o custo em si não é um problema (nem era no Flex 1.5!) se o benefício for o desejado (já diz a propaganda do MasterCard), ainda mais no mundo corporativo. Em segundo lugar porque o Flex 2 possui uma versão gratuíta. O compilador (que converte códigos MXML e ActionScript para o arquivos .SWF) é gratuíto, assim como o Flex Framework, conjunto de componentes (DataGrid, TabNavigator, etc..). O que a Adobe irá vender, por um preço acessível (umas 1000 doletas), é a IDE do Flex – o Flex Builder, um approach muito similar com o que a Microsoft faz com suas tecnologias (vendendo o VisualStudio).

E mais ainda do que ser gratuíto, qualquer web hosting atual é compatível com Flex 2. Não será mais necessário instalar o Flex Server (a não ser que você queira utilizar os recursos avançados do Flex Data Services para comunicação). O compilador irá gerar o arquivo .swf locamente na máquina do desenvolvedor e basta copiar o arquivo para um servidor.

Mais simples do que isso… só se a aplicação for gerada automaticamente! Tá bem, ainda não é bem assim, mas a Adobe está se esforçando. O ColdFusion MX 7 Flex Connectivity Updater (gratuíto, claro. Cobre de seu hosting provider a instalação dessa atualização no servidor quando a versão final for disponibilizada) que permite que o Flex conecte-se e comunique-se com o servidor ColdFusion via Flash Remoting (tal como seria necessário o Flex Data Services para conectar-se ao Java) e, utilizando o utilizando o ColdFusion Extensions for Flex Builder possibilita que o Flex Builder conecte-se automaticamente ao banco de dados (através do RDS do ColdFusion) e gere pedaços da aplicação, principalmente formulários de cadastro (inserir, visualizar, editar e deletar)! Uma mão na roda, com todo o código Flex e ColdFusion gerado automaticamente.

Para os interessados, vale muito a pena dar uma olhada no Flex 2 Beta 3, disponível agora há pouco no Adobe Labs. E que as RIAs venham de vez!


Adobe Flex e Ajax desmistificados

Recentemente eu e o Beck Novaes tivemos uma troca de idéias sobre o Flex e o Ajax, ao vermos mensagens em listas de discussão, artigos e no mercado sobre um possível embate entre essas tecnologias.

Eu já havia feitos comentários sobre esse assunto (na lista CF-Brasil e na lista Flex-Brasil por exemplo), mas esse artigo apresenta de maneira mais clara e concisa as minhas idéias sobre o assunto, com o o objetivo de desmistificar a concorrência entre Adobe Flex e Ajax através de sua possível complementação para desenvolvimento da nova geração de aplicativos: rich internet applications. O Beck também postou suas considerações sobre o assunto no blog da DClick.

Leia o resto deste post »


Cairngorm – Parte 6

Essa é a sexta e última parte (parte 1, parte 2, parte 3, parte 4 e parte 5) do conjunto de artigos sobre o Cairngorm. Essa última parte apresenta um resumo sobre o funcionamento da microatquitetura proposta, bem como um interessante exemplo de implementação de uma nova funcionalidade no Cairngorm Store (o Flex Store convertido para o Cairngorm).

Novamente, reitero que é interessante ler o artigo original de Steven Webster na íntegra para um melhor entendimento. Essas sínteses apresentadas aqui no blog são apenas como referência e fazem parte de um estudo que conduzi com minha equipe atual. E nem estes devem ser considerados únicas fontes de informação de arquiteturas de aplicação – aspecto vital para um bom produto final.

Leia o resto deste post »


Cairngorm – Parte 5

Dando seqüência à quarta parte, esta quinta e penúltima discute as implementações do Service Locator e do Business Delegate. Um dos principais pontos é que cada Command é de um use case, e ainda assim pode chamar o mesmo método no servidor, o que justifica o delegate (veja mais sobre as responsabilidade de cada pattern do Cairngorm nesse post. Também é comentado sobre o desenvolvedor responsável pela integração com o server-side e o desenvolvedor do cliente.

Novamente, recomendo que o artigo original seja lido na íntegra para um melhor aproveitamento. Esse conjunto de posts é referente a um estudo realizado e não deve ser considerado única fonte de referência no assunto.

Leia o resto deste post »


Cairngorm – Parte 4

Essa é a parte 4 do artigo (que contém exemplos práticos, baseados no Cairngorn Store). Este é referente a microarquitetura Service to Worker, que envolve os design patterns Front Controller, Event Broadcaster e Command, que em conjunto integram-se com o Model Locator e o Value Object. O original em inglês está disponível aqui.

Um dos maiores paradigmas desse estilo de desenvolvimento está nesse trecho do artigo: “No more scattering of business logic across an ever-growing ecosystem of MXML components. No more monolithic classes that state ‘if the application just did this, then do that; but if it did this, then do the next thing…’

Leia o resto deste post »


Cairngorm – Parte 3

Dando continuidade da série (parte 1, parte 2) esta terceira parte é referente à view. O original, de Steven Webster, no qual baseio esse estudo que conduzi com minha equipe, está aqui.

Os pontos mais interessante foram as best practices sugeridas, dentre elas uma que sempre sugeri: nomes semânticos para os elementos (componentes, telas e afins) – não me venha com nomes em código!; e a questão de disparar eventos, muito mais utilizado agora no Cairngorm 2 (e reformulado no Flex 2).

Leia o resto deste post »


Cairngorm – Parte 2

Na seqüência do primeiro artigo, essa segunda parte discute os desafios do desenvolvimento das RIAs, e foca no primeiro deles: manter o estado no cliente, e discute a solução desses problemas com os patterns VO (ou DTO, Data Transfer Object) e ModelLocator.

O original no qual esse estudo é baseado está disponível do Developer Center.

Leia o resto deste post »