Twitter!

Como todos devem ter percebido, nos últimos meses o CSS3 e o HTML5 tem ganho um grande destaque no desenvolvimento web. Grandes empresas como o Google, Microsoft, Adobe e Apple estão apoiando fortemente o desenvolvimento web utilizando WebStandards. Caso você já conheça algo sobre CSS, provavelmente deve saber como é complicado a organização desses documentos em um projeto de médio ou grande porte. Dado esses problemas conhecidos, foram surgindo os chamados pré-processadores de CSS, que viabilizam a criação de documentos de estilo, adicionando novas funcionalidades.

Hoje vamos conhecer o LESS, The Dynamic Stylesheet Language. O objetivo dessa biblioteca em javascript é prover uma série de funcionalidades para as, usualmente criadas a mão, folhas de estilos. Recursos tais como, variáveis, mixins (Multiple Inheritance, Traits), mixins parametrizáveis, funções, namespaces, importação, etc. Vamos aprender como utilizar os principais recursos dessa biblioteca em um projeto e como aproveitar o melhor dessa biblioteca para organizar corretamente nossas folhas de estilo.

Variables

As variáveis ajudam-nos a definir valores que podem ser utilizados em diversas regras do nosso CSS. Elas possuem escopo assim como em uma linguagem de programação orientada a objetos, trocando em miúdos:

O que é interessante no uso de variáveis é a reutilização e organização. Imagine uma design guideline onde existem RGBs específicos a serem seguidos, essas cores poderiam ser definidas em um documento chamado color_variables.less e adicionados ao nosso arquivo principal utilizando a clausula @import.

@Import – Importando outros arquivos

Quando um arquivo LESS é importado, todas as suas variáveis e mixins são adicionados ao arquivo principal. Os escopos serão mantidos e a extensão .less é opcional.

@import “lib.less”
@import “lib”

É possível utilizar pastas nas clausulas de @import:

@import “where/is/my/stylesheet.less”
@import “where/is/my/stylesheet”

Mixins

No LESS, mixis são como uma espécie de classe CSS que pode ser reutilizada em diversas outras regras. Quando utilizadas, todas as propriedades definidas no mixin são adicionadas a regra onde a mesma foi adicionada, caso um mixin mude, todas as regras que o referenciam serão também modificadas.

Imagine o conceito de mixin como classes CSS orientadas a objeto, o que é interessante do mixin é que temos aqui algo como uma herança múltipla, caso uma mesma instrução seja declarada em mixins diferentes, e esses mixins adicionados a uma regra, o mixin declarado por último terá vantagem na construção final do CSS da regra onde foi adicionado.

Quando modificarmos o mixin .bordered, todos os elementos que o estão utilizando serão modificados. Reutilização!
Vamos para um exemplo mais usável para exemplificar como é um mixin parametrizável.

É importante destacar que um mixin pode conter diversos parâmetros. Isso pode ser feito da seguinte forma:

Nested Rules

Com o LESS você pode criar suas regras de CSS utilizando uma espécie de hierarquia. Vamos ver como isso funciona na prática.

Com o LESS, o mesmo CSS acima poderia ser escrito da seguinte forma:

Depois de processado, o CSS será exatamente igual. Você não precisa utilizar esse esquema de hierarquia caso não queira, é importante lembrar que o LESS é apenas uma extensão do CSS, se for de desejo do desenvolvedor, podemos escrever um código LESS sem usar nenhum recurso especial, como se fosse um CSS tradicional.

Operations

Com o LESS o seu CSS sabe fazer contas. Qualquer número, cor ou variável pode ser utilizada em uma operação aritmética.
Ele sabe identificar quando estamos utilizando uma cor ou um número, por exemplo:

Assim como no javascript, é possível também utilizar parênteses nas suas operações:

Color Functions

Na minha opinião um dos recursos mais úteis durante o desenvolvimento de uma aplicação. Podemos efetuar operações em cima de RGBs, por exemplo, imagine que o layout do seu website foi criado baseado-se em apenas uma cor, utilizando diversos tons dessa cor. Com o LESS é possível utilizar métodos pré-definidos como lighten, saturate, darken, fadein, fadeout e spin. Esses métodos retornam sempre um RGB que pode ser utilizado em seu LESS. Vejamos alguns exemplos:

É possível também extrair informações de uma determinada cor para ser utilizada em outra.
Isso é feito a partir dos métodos hue, saturation e lightness.

Namespaces

Em dado momento necessitamos organizar uma série de mixins e variáveis. Para isto podemos utilizar um conceito presente no LESS chamado Namespaces. Assim como em linguagens de programação orientadas a objetos, que possuem o conceito de pacotes, os namespaces fornecem encapsulação para nossas folhas de estilo. Isso pode ser implementado facilmente utilizando a mesma notação de ID do CSS tradicional. Vejamos.

Verifique que acima, criamos um mixin chamado button dentro do namespace bundle. Para o utilizarmos devemos fazer da seguinte forma:

Uma utilização muito comum dos namespaces é na criação de pequenas bibliotecas de utilidades. Imagine que sua empresa pode possuir uma série de arquivos LESS, e em um determinado projeto você necessita de acesso a esses mixins, variáveis, etc. Organizar seus documentos com namespaces fácilita a visualização e localização de uma determinada instrução no seu documento LESS, como por exemplo, um mixin customizado que pode ser facilmente encontrado a partir da sua indicação de namespace.

Conclusão

Como podemos ver, o LESS facilita uma série de tarefas que são praticamente impossíveis de serem efetuadas pelo CSS tradicional.
Aconselho a todos que tenham interesse em se aprofundar mais na biblioteca a conhecer o website (http://lesscss.org/). Lá você poderá encontrar a documentação com maior riqueza de informações também poderá ver alguns exemplos de código que não foram abordados nesse post.

Qualquer dúvida, sinta-se a vontade e envie-nos um comentário!
Abraço!

Ol? Pessoal.

Este ? o segundo post de uma s?rie de post's que estou fazendo, em formato de resenha. Como partida, estou lendo o livro Management 3.0 Leading Agile Developers, Developing Agile Leaders e sintetizando ele aqui. Confira aqui a parte 1.

Teoria dos sistemas complexos

A teoria dos sistemas complexos ? uma teoria advinda da matem?tica que se concentra em entender porque alguns tipos de sistemas s?o est?veis e porque alguns outros tipos n?o s?o. Levando para o campo de desenvolvimento de software a referida teoria nos ajuda a explicar porque alguns projetos s?o est?veis e porque outros n?o s?o.

Desenvolvimento de software pode ser visto como um sistema complexo adaptativo, onde as intensas intera??es e feedbacks fornecem oportunidade de melhoria aprendizado e conhecimento.

MULTIDISCIPLINARIDADE

A ideia de segregar pessoas que fazem trabalhos diferente oferece um impacto negativo ? performance da organiza??o. Esse tipo de segrega??o promove silos/feudos funcionais que dificultam a comunica??o e a amplifica??o do aprendizado e conhecimento na dimens?o ontol?gica da organiza??o (veja a teoria da cria??o do conhecimento). Corroborando com os princ?pios do manifesto ?gil, a teoria da complexidade tamb?m ? a favor da forma??o de equipes multidisciplinares.

O CORPO DE CONHECIMENTO DE SISTEMAS

N?o h? uma ?nica defini??o gen?rica para explicar a complexidade, cada sistema ? diferente, peculiar e por vezes suas defini??es s?o complementares, as vezes sobrepostas e as vezes contradit?rias. No entanto, existem v?rios estudos que se concentram em diferentes ?reas e que trouxeram uma contribui??o significativa para o campo dos sistemas complexos: Entre esses estudos est?o: a teoria evolucion?ria (evolutionary theory), a teoria dos jogos (game theory) a teoria do caos (chaos theory), a teoria dos sistemas din?micos (dynamical systens theory), entre outras. A figura abaixo apresenta o corpo de conhecimento de sistemas.

SIMPLICIDADE: UM NOVO MODELO

“Simplicidade normalmente est? relacionada com peso (o qu?o dif?cil ?) para algu?m tentar explicar ou entender algo. Qualquer coisa que ? f?cil de entender ou explicar ? simples, em contraste com algo complicado.”

Antes de discutir simplicidade, faz-se necess?rio entender cada terminologia abaixo:

• Simples: f?cil de entender
• Complicado: muito dif?cil de entender

• Ordenado: totalmente previs?vel
• Complexo: um pouco previs?vel (mas com muitas surpresas)
• Ca?tico: completamente imprevis?vel

Na literatura, alguns modelos diferenciam a referida terminologia, como os modelos de David Snowden, que descreve um modelo contendo quatro dom?nios(simples, complicado, complexo e ca?tico) e modelo de Ralph Stacey que cria algo similar. Ele mostra o simples, complicado, complexo, e ca?tico, como quatro ?reas com base em duas dimens?es: o grau de concord?ncia e o grau de incerteza.

A NOVA ERA: PENSAMENTO COMPLEXO (COMPLEXITY THINKING)

Quando voc? aplica a teoria de sistemas complexos (complex systems theory) em desenvolvimento e gerenciamento de software, voc? est? tratando sua organiza??o como um sistema.

A din?mica do sistemas(System dynamics) – n?o confunda com a teoria dos sistemas din?micos(dynamical systems theory), foi uma das primeiras t?cnicas criadas para mostrar como eventos aparentemente simples podem causar comportamentos inesperadas na organiza??o.

A System dynamics percebe a organiza??o como uma estrutura interligada e mutuamente dependente das partes. A System dynamics tem ajudados os gestores ? melhorar sua compreens?o dos processo de neg?cio.

Uma outra t?cnica similar ? chamada de pensamento sist?mico (systems thinking), popularizada no livro The Fifth Discipline (que tamb?m pretendo fazer resenhas dele aqui no blog ). Essa t?cnica aborda o entendimento de como o pensamento influencia o outras partes como um todo e defende que o primeiro passo para se tornar uma organiza??o de aprendizagem ? ela compreender, como um sistema hol?stico, o que ela faz e como realmente faz.

O estudo da complexidade em sistemas sociais ? chamado de complexidade social (social complexity). A complexidade social ? o estudo de grupos sociais em sistemas adaptativos complexos.

System dynamics e systems thinking percebem a n?o linearidade, mas eles ainda partem da ideia que, de alguma forma, a alta ger?ncia constr?i o “tipo certo” de organiza??o que produz o “tipo certo” de resultado. Entretanto, atualmente os gestores percebem que para gerenciar a complexidade social, eles precisam entender como as coisas “emergem” e n?o como elas s?o “constru?das”. O modelo de gest?o 3.0 aplica o pensamento complexo (complexity thinking) e assume que os gestores n?o podem construir nem dirigir uma equipe auto-organizada. Em vez disso, a equipe deve emergir naturalmente. O modelo reconhece que organiza??es produtivas n?o s?o gerenciadas dirigidas por modelos e planos. Em vez disso, deve emergir atrav?s do poder da evolu??o da auto-organiza??o.

Obs: Para mim esses assuntos s?o complicados. Portanto, sinta-se a vontade para criticar, corrigir ou acrescentar valor nos coment?rios.

Ol? Pessoal.

Este post ? o primeiro de uma s?rie de posts que pretendo publicar, em formato de resenha, sobre “livros que estou lendo“. Como partida, fiz a primeira de v?rias outras do livro Management 3.0 Leading Agile Developers, Developing Agile Leaders. O livro pretende mostrar como ser um bom gerente ?gil. A base para isso ? o entendimento sobre pessoas e sistemas e a maneira como as pessoas pensam sobre sistemas. Antes de tudo, os gerentes devem compreender como sistemas sociais funcionam.

GEST?O 1.0 = HIER?RQUICA

Representada por organiza??es hierarquizadas, onde o comando parte da alta ger?ncia funcional, de cima para baixo. Aqueles que est?o no alto da hieraquia tem altos sal?rios, grandes egos. em contrapartida, aqueles que est?o na base da hierarquia normalmente tem baixos sal?rios, poucas responsabilidades (especializado), e pouca motiva??o para fazer um bom trabalho. Fortemente baseada nos modelos fordistas e tayloristas do in?cio do s?culo. Sua gest?o ? focada no comando controle.

GEST?O 2.0 = MODISMO

S?o as organiza??es essencialmente “Gest?o 1.0”, mas que cont?m pessoas que j? perceberam que esse modelo n?o funciona bem “fora da caixa”. Ent?o s?o criados v?rios modelos adicionais de servi?os e processos como BSB, six-sigma, ITIL, Cobit, Qualidade total, entre outros.

GEST?O 3.0 = COMPLEXIDADE

? uma ger?ncia que percebeu que a organiza??o ? uma rede, formada por pessoas, seus relacionamentos e sua complexidade social e n?o por divis?es funcionais hier?rquicas. Abomina o comando-controle e advoga por uma cultura de lideran?a, hol?stica, org?nica, enxergando a organiza??o como um sistema (complexo) vivo e n?o apenas como uma m?quina.

CAUSALIDADE

O determinismos causal infere que as coisas que acontecem hoje s?o causadas por outras coisas que aconteceram antes. Podemos utilizar o determinismo causal, por exemplo, para prever com precis?o quando ser? a pr?xima vez que o cometa Halley passar? pr?ximo da atmosfera terrestre, com base na ?ltima vez que ele passou. Nesse sentido, o determinismo causal habilita que os desenvolvedores ? projetar, planejar e prever tudo o que dever? ser feito no projeto de desenvolvimento de software. Se abstra?rmos qualquer problema de bug, altera??o de requisitos ou cat?strofe interplanet?ria, a causalidade pemite prever com bastante precis?o. Pena que n?o podemos utilizar tamb?m c?lculos astron?micos para determinar a complexidade sist?mica onde projetos de software est?o inseridos. lol.

COMPLEXIDADE

Complexidade n?o tem rela??o com v?rias coisas pra fazer simultaneamente ou com em fazer coisas grandes, a complexidade ? intr?nseca. N?o obstante, v?rias teorias como por exemplo: teoria dos sistemas din?micos (Dynamical systems theory), teoria do caos (chaos theory), teoria dos jogos(game theory), tentam explicar por que alguns fen?menos s?o imprevis?veis e n?o podem ser calculados apenas com a experi?ncia e observa??es emp?ricas. O campo da ci?nica que estouda esses fen?menos ? nomeada como teoria da complexidade (complexity theory).

A teorias da complexidade, de certa forma, ? um “conforto” para gerentes, lideres de time e gestores em organiza??es que desenvolvem software. Isso significa que nem tudo est? perdido, h? um novo paradigma cient?fico, baseado na complexidade de sistemas, que ajuda a entender o problema da volatilidade e incertezas em desenvolvimento de softwares.

REDUCIONISMO

O reducionismo ? a abordagem que se baseia na desconstru??o de algo em partes menores, para analis?-las e a? sim entender o todo,. Entendimento do sistema pelo entendimento das partes. Essa t?cnica pode ser utilizada, por exemplo, para desconstruir um computador para entender como ele funciona, para dissecar um animal para entender como seus org?os internos funcionam. No entanto, em algumas ?reas, onde a imprevisibilidade ? uma constante, a utiliza??o da abordagem reducionista n?o ? capaz de determinar, por meio da desconstru??o e an?lise das partes, o entendimento do todo. Enquadra-se nisso, estudos sobre: organismos, consci?ncia humana, as economias, climas, e projetos de software

HOLISMO

O Holismo ? a ideia de que o comportamento do sistema n?o pode ser completamente determinado pelos seus componentes isolados. A vis?o hol?stica pode ser vista como o oposto ao reducionismo, onde a vis?o do sistema como um todo determina comportamentos importantes para ele.

GERENCIAMENTO ?GIL

Uma das bases do desenvolvimento ?gil de software est? na teoria da complexidade. Os valores e princ?pios ?geis corroboram para reconhecer que o determinismo causal ? insuficiente para entregar projetos de sucesso. Conceitos bem conhecidos como auto-organiza??o, multi-disciplinaridade, autonomia s?o oriundos da ci?ncia da complexidade.

O MODELO DA GEST?O 3.0

O modelo da gest?o 3.0 mostra como gerenciar equipes sabendo que os sistemas s?o complexos, n?o lineares, n?o previs?veis e carentes de adaptabilidade. Para o entendimento de sistemas complexos, ? necess?rio, a priori, uma vis?o hol?stica do todo como objetivo de estudar a complexidade social. A gest?o 3.0 ? um modelo de gest?o ?gil que aplica a teoria dos pensamentos complexos (complexity thinking) em equipes de desenvolvimento de software ?gil. Sob o olhar do pensamento dial?tico, esse modelo compreende os encalsos do reducionismo no ambiente de desenvolvimento de software (tese), aceita a oposi??o e acredita em uma vis?o hol?stica, sist?mica e social (ant?tese), para criar uma nova ideia denominada gest?o 3.0 (s?ntese). A figura abaixo ilustra o modelo de gest?o 3.0.

Na defini??o da teoria da cria??o do conhecimento organizacional [Nonaka e Takeuchi, 1995] definiram duas dimens?es para a cria??o do conhecimento:

i) a dimens?o epistemologica: onde ? feita uma distin??o entre o conhecimento t?cito e o expl?cito para a cria??o do conhecimento. Essa distin??o corrobora com a estabelecida por [Polanyi, 1967]. O conhecimento t?cito ? individual, pertence a pessoa ? espec?fico ao contexto e ? dif?cil de ser registrado e compartilhado. J? o conhecimento expl?cito pode ser registrado em meios f?sicos ou digitais em linguagem natural, formal, ou sist?mica;

ii) a dimens?o ontol?gica: onde enfatiza a cria??o do conhecimento organizacional em oposi??o ? cria??o do conhecimento individual, passando por v?rios n?veis de cria??o do conhecimento (individual, grupal, organizacional e inter-organizacional). Segundo [Nonaka e Takeuchi, 1995] o conhecimento s? pode ser criado pelos indiv?duos. O papel da organiza??o ? apoiar e motivar os indiv?duos criativos e lhe proporcionar um ambiente adequado para a cria??o do conhecimento. Neste contexto, o conhecimento organizacional ? o resultado do conhecimento individual amplificado, registrado e mantido pela organiza??o.

Na teoria da cria??o do conhecimento organizacional, conforme ilustrado na figura do espiral do conhecimento, as dimens?es epistemol?gica e ontol?gica suportam o “`espiral”' da cria??o do conhecimento [Nonaka e Takeuchi, 1995]. A referida espiral surge quando, por meio de intera??es entre o conhecimento t?cito e o conhecimento expl?cito, existe uma amplifica??o do conhecimento come?ando pelo conhecimento do indiv?duo, passando pela forma??o do conhecimento do grupo, estabelecendo o conhecimento da organiza??o e por fim convergindo no conhecimento da interorganiza??o.

No centro dessa teoria, conforme ilustrado na figura no modelo SECI abaixo, est? os quatro modos de convers?o do conhecimento criados a partir da intera??o entre t?cito e expl?cito. Esses modos de convers?o foram um modelo que descreve como o conhecimento t?cito ? criado atrav?s da socializa??o, convertido de t?cito para expl?cito atrav?s da externaliza??o, recombinado com outras formas de conhecimento expl?cito atrav?s da combina??o e convertido, novamente, em conhecimento t?cito atrav?s da internaliza??o.

i) socializa??o: quando o conhecimento t?cito se amplifica e ? formado um novo conhecimento t?cito. A socializa??o acontece quando h? compartilhamento de experi?ncias por meio observa??es, de forma emp?rica, diretamente de um indiv?duo para outro, com utiliza??o de linguagem ou apenas atrav?s de observa??es.

ii) externaliza??o: quanto o conhecimento t?cito se amplifica e ? formado um novo conhecimento expl?cito. A externaliza??o acontece quando o conhecimento t?cito ? registrado e pode ser compartilhado em um formato documental, met?fora, mapa mental, modelos, conceitos, hip?teses, etc.

iii) combina??o: quanto o conhecimento expl?cito se amplifica e ? formado um novo conhecimento expl?cito. A combina??o acontece quando um conhecimento j? externalizado ? compilado com outros conhecimento tamb?m j? extenalizados a fim de gerais um novo conhecimento externalizado. Normalmente a combina??o ocorre atrav?s de documentos, reuni?es, conversas ao telefone ou em comunica??o computadorizada.

iv) internaliza??o: quando o conhecimento expl?cito se amplifica e ? formado um novo conhecimento t?cito. A internaliza??o acontece quando o indiv?duo sintetiza e incorpora??o um conhecimento explicito para seu conhecimento t?cito. A internaliza??o ? concebido com o “aprender fazendo”, e incorpora no indiv?duo o “knowhow” t?cnico.

O paradigma de [Nonaka e Takeuchi, 1995] sobre a cria??o do conhecimento destaca tanto o processo de cria??o do conhecimento quanto as condi??es sob as quais o conhecimento ? criado. Essencial para esse paradigma ? a intera??o entre o conhecimento t?cito e expl?cito. A cria??o do conhecimento ? uma espiral, conforme ilustrado na figura do espiral do conhecimento e descrita pelo modelo SECI.

Refer?ncia:

[Nonaka e Takeuchi, 1995] Ikujiro Nonaka and Hirotaka Takeuchi. The knowledge-creating company: how Japanese companies create the dynamics of innovation. Oxford University Press, New York, 1995.

[Polanyi, 1967] Michael Polanyi. The tacit dimension. An anchor book: philosophy. Doubleday, Garden City, NY, 1967.

[PT-BR]
Criei uma biblioteca q pode ser muito util para quem trabalha com projetos usando Swiz. O projeto ainda é beta, mas já coloquei no github para vcs poderem acompanhar evoluções/correções. Por favor, leiam o arquivo README (html ou RichText).

Valeu!

[EN-US]
I’ve created a simple project named [DynamicService] custom metadata for Swiz Framework (Adobe Flex) and I’ve posted on github. Let you know that’s a beta project, but you can download it. Please read the README file (html or rtf extension).

Github link: https://github.com/mariojunior/DynamicServices-Custom-Metadata

Thanks.

Olá.

Escrevendo o post Java + MongoDB + Spring Data descobri o Spring Data JPA
e fiquei surpreso em descobrir algumas features como a criação de repositórios e consultas dinâmicas.
Neste Post vou falar um pouco sobre o Spring Data JPA e como ele pode lhe proporcionar uma maneira rápida e elegante de implementar seus repositórios.

O Spring Data JPA tem como principal objetivo facilitar a implementação das camadas de acesso a dados.
O Spring fica responsável pela implementação dos repositórios e oferece algumas funcionalidades sofisticadas e comuns na maioria dos CRUDs baseado na entidade que esta sendo gerenciada.

Nessa aplicação vou usar as entidades Contact, Phone, e o repositório ContactRepository.

As entidades são bem simples, é anotadas com o mapeamento de seus atributos e relacionamentos.
Contact.java

@Entity
@Table(name="phones")
public class Phone 
  @Id
  @GeneratedValue(strategy = GenerationType.AUTO)
  private Long id;

  @ManyToOne
  @JoinColumn(name="id_contact")
  private Contact contact;
  //getter and setter methods 
  ...

Phone.java

@Entity
@Table(name="contacts")
public class Contact 

   @Id
   @Column(name="id_contact")
   @GeneratedValue(strategy = GenerationType.AUTO)
   private Long id;

   @Column(name="name")
   private String name;

   @Column(name="email",unique=true)
   private String email;

   @OneToMany(mappedBy="contact",cascade=CascadeType.ALL, fetch=FetchType.LAZY)
   @Fetch(FetchMode.JOIN)
   @private Set<Phone> phones = new HashSet<Phone>();

  //getter and setter methods 
  ...

ContactRepository.java

public interface ContactRepository extends JpaRepository<Contact, Long> 

    public Contact findByEmail(String email);

Até aqui nada de novo, porem agora como a “mágica” do Spring JPA ..rsrs

A interface do repositório estende JpaRepository, essa interface tem alguns métodos comuns como findAll, findOne, save, delete, etc…
Normalmente teríamos que implementar essa interface criando uma classe ContactRepositoryImpl e registra-la como um bean do spring
para que então possamos utilizar o repositório.

Com o Spring JPA não é necessário escrever essa implementação ..
Não é magia meus amigos, é tecnologia !!!…rsrs

O Spring JPA vai procurar por interfaces de repositórios que estendam a interface JpaRepository,
e então criar uma implementação para a interface e registra-la como um bean.

Para isso so é necessário apenas adicionar a tag jpa:repositories no contexto do spring,
com isso o Spring sabe onde procurar os repositórios que ele teve implementar.

applicationContext.xml

// Declaração dos Beans, TransactionManager, DataSource, etc...

 base-package="br.com.flexria.springjpa.repository" />

Com isso a implementação do repositório já esta pronta para ser injetada é utilizada na aplicação.

@Autowired
ContactRepository repository;

repository.save(contact);

repository.delete(contact);

List<Contact> list = contactRepository.findAll();

Isso por si so ja é algo incrível so que o Spring Data JPA vai alem.

Algo que ja é comum no Rails, são os Dynamic attribute-based finders que é a possibilidade de realizar buscas dinâmica baseadas nos atributos do objeto
Em rails temos :

//"SQL : SELECT * FROM contacts WHERE email = 'fabio.bat.silva@gmail.com'"

Contact.where(:email =>"fabio.bat.silva@gmail.com")

//Usando Dynamic attribute-based finders
Contact.find_by_email "fabio.bat.silva@gmail.com"

É exatamente isso que o Spring Data JPA faz,
além de implementar do repositório com ele é possível utilizar buscas dinâmica baseadas nos atributos do objeto.

   // HQL : select c from Contact c where c.email = ?1
    public Contact findByEmail(String email);

   // HQL : select c from Contact c where c.name like ?1
    public List<Contact> findByNameLike(String name);

Com base em algumas palavras chaves varias consultas podem ser feitas :

Leia o resto aqui.

Olá.

Escrevendo o post Java + MongoDB + Spring Data descobri o Spring Data JPA
e fiquei surpreso em descobrir algumas features como a criação de repositórios e consultas dinâmicas.
Neste Post vou falar um pouco sobre o Spring Data JPA e como ele pode lhe proporcionar uma maneira rápida e elegante de implementar seus repositórios.

O Spring Data JPA tem como principal objetivo facilitar a implementação das camadas de acesso a dados.
O Spring fica responsável pela implementação dos repositórios e oferece algumas funcionalidades sofisticadas e comuns na maioria dos CRUDs baseado na entidade que esta sendo gerenciada.

Nessa aplicação vou usar as entidades Contact, Phone, e o repositório ContactRepository.

As entidades são bem simples, é anotadas com o mapeamento de seus atributos e relacionamentos.
Contact.java

@Entity
@Table(name="phones")
public class Phone 
  @Id
  @GeneratedValue(strategy = GenerationType.AUTO)
  private Long id;

  @ManyToOne
  @JoinColumn(name="id_contact")
  private Contact contact;
  //getter and setter methods 
  ...

Phone.java

@Entity
@Table(name="contacts")
public class Contact 

   @Id
   @Column(name="id_contact")
   @GeneratedValue(strategy = GenerationType.AUTO)
   private Long id;

   @Column(name="name")
   private String name;

   @Column(name="email",unique=true)
   private String email;

   @OneToMany(mappedBy="contact",cascade=CascadeType.ALL, fetch=FetchType.LAZY)
   @Fetch(FetchMode.JOIN)
   @private Set phones = new HashSet();

  //getter and setter methods 
  ...

ContactRepository.java

public interface ContactRepository extends JpaRepository 

    public Contact findByEmail(String email);

Até aqui nada de novo, porem agora como a “mágica” do Spring JPA ..rsrs

A interface do repositório estende JpaRepository, essa interface tem alguns métodos comuns como findAll, findOne, save, delete, etc…
Normalmente teríamos que implementar essa interface criando uma classe ContactRepositoryImpl e registra-la como um bean do spring
para que então possamos utilizar o repositório.

Com o Spring JPA não é necessário escrever essa implementação ..
Não é magia meus amigos, é tecnologia !!!…rsrs

O Spring JPA vai procurar por interfaces de repositórios que estendam a interface JpaRepository,
e então criar uma implementação para a interface e registra-la como um bean.

Para isso so é necessário apenas adicionar a tag jpa:repositories no contexto do spring,
com isso o Spring sabe onde procurar os repositórios que ele teve implementar.

applicationContext.xml

// Declaração dos Beans, TransactionManager, DataSource, etc...

<jpa:repositories base-package="br.com.flexria.springjpa.repository" />

Com isso a implementação do repositório já esta pronta para ser injetada é utilizada na aplicação.

@Autowired
ContactRepository repository;

repository.save(contact);

repository.delete(contact);

List list = contactRepository.findAll();

Isso por si so ja é algo incrível so que o Spring Data JPA vai alem.

Algo que ja é comum no Rails, são os Dynamic attribute-based finders que é a possibilidade de realizar buscas dinâmica baseadas nos atributos do objeto
Em rails temos :

//"SQL : SELECT * FROM contacts WHERE email = 'fabio.bat.silva@gmail.com'"

Contact.where(:email =>"fabio.bat.silva@gmail.com")

//Usando Dynamic attribute-based finders
Contact.find_by_email "fabio.bat.silva@gmail.com"

É exatamente isso que o Spring Data JPA faz,
além de implementar do repositório com ele é possível utilizar buscas dinâmica baseadas nos atributos do objeto.

   // HQL : select c from Contact c where c.email = ?1
    public Contact findByEmail(String email);

   // HQL : select c from Contact c where c.name like ?1
    public List findBynameLike(String email);

Com base em algumas palavras chaves varias consultas podem ser feitas :

Repositórios dinâmicos, consultas dinâmicas, Buscas baseadas em NamedQuery ou anotações, etc..
com certeza tem muita coisa a ser explorada no Spring Data JPA, me surpreendi com a facilidade e agilidade.

Vale apena dar uma conferida na documentação do Spring Data JPA

E Para quem tiver o interesse deixei a app no git
https://github.com/FabioBatSilva/spring-data-jpa

Abraço e até a próxima….

Click aqui para ver o post Original

Fabio B. Silva
http://www.flexria.com.br

Salve pessoal
Estou voltando à ativa nesse blog, espero que agora eu encontre tempo para criar os tutoriais.

Inicialmente gostaria de deixar claro que o foco desse blog não é o público que eu chamo de “Hard ActionScript Developer” o meu foco são aqueles desenvolvedores que estão iniciando ou que são intermediários no mundo do Actionscript 3.0, então nem sempre vamos focar no “melhor código” para os exemplos, mesmo porque eu nem teria tempo para fazer isso, na verdade a minha intenção e abordar superficialmente algumas coisas que vejo no meu dia-a-dia e apresentar coisas realmente usuais para todos.

Dito isso, fica claro que não tenho a intenção de criar uma metodologia definitiva para desenvolvimento, então pegue leve nas críticas =)

Hoje vamos falar sobre a utilização do Gaia Framework para desenvolvimento de pequenos projetos (games, hotsites etc…)

O que é o Gaia Framework?

O Gaia Framework é um projeto Open-Source para Actionscript 2.0 e 3.0 que visa facilitar sua vida na hora de desenvolver projetos em Flash, ele reduz drasticamente o tempo que você leva desenvolvendo, pois cria automaticamente alguns dos processos comuns a qualquer site em Flash.
Com o Gaia Framework é possível criar sites usuais em flash em pouco tempo com características que você levaria horas para fazer tais como:

1. Navigation
2. Transitions
3. Preloading
4. Asset Management
5. Dynamic Font Loading
6. SEO
7. DeepLinks

Para maiores informações e detalhes sobre o que é o Gaia Framework acesse o site

Instalando o Gaia Framework

Acesse o site e faça download do arquivo MXP do Gaia Framework, feito isso clique duas vezes no arquivo para instalar. Abra o Adobe Flash Cs5 e vá na aba Help > Manage Extentions ,certifique-se que o Gaia Framework esteja instalado corretamente como na imagem abaixo:

Pronto, agora o seu Adobe Flash Cs5 já está pronto para trabalhar com o Gaia Framework.

Instalando Gaia Site Creator

O Gaia Site Creator é um aplicativo AIR que facilita ainda mais o desenvolvimento com Gaia Framework ele irá nos ajudar na hora de criar o arquivo “site.xml” que define as “paginas” que nosso site em Flash vai ter, sobre esse arquivo XML vamos falar nas próximas aulas, por hora apenas acesse o site e instale o Gaia Site Creator.

Criando 1º projeto com Gaia Framework

Com o Adobe Flash Cs5 aberto vá na aba Window > Other Panels > Gaia Framework
Uma janela como essa vai se abrir para você:

1. Criar um novo projeto em Actionscript 3.0
2. Criar um novo projeto em Actionscript 2.0 (sai fora, credo!)
3. Importar um projeto existente
4. Fazer uma doção para o Steven Sacks =)
5. Lista de projetos criados (ainda em branco)

Esse é o painel que você vai trabalhar durante todo o tempo de desenvolvimento com o Gaia Framework aconselho você a deixar ele em um lugar de fácil acesso durante o desenvolvimento.
Agora é a hora de começarmos realmente a desenvolver utilizando o Gaia Framework, com o painel do Gaia Framework aberto clique no botão “Create AS3″ e configure como a imagem abaixo:

1. Nome do projeto que vamos desenvolver
2. Pasta raiz do projeto
3. Versão do Flash Player que esse projeto vai ser compilado
4. Versão do Gaia Framework e do Greensock (motor de animação) utilizado
5. Tamanho do Stage, Framerate e cor
6. Estrutura de pastas criada pelo Gaia Framework aconselho a deixar dessa forma
7. Tipo de projeto utilizado, nesse exemplo vamos usar o FlashDevelop para desenvolver

Com todos esses requisitos preenchidos clique no botão “Create New Project” para criar o projeto do Gaia Framework.
Pronto, o Gaia Framework acabou de criar a estrutura básica para trabalharmos o projeto veja como ficou nossa estrutura:

1. Arquivo de configuração do Gaia Framework
2. Arquivo de projeto do FlashDevelop
3. Pastas com arquivos publicáveis (swf, imagens, XML…)
4. Pasta com os arquivos FLAs
5. Pasta com os arquivos .as
6. Pasta com os templates (não vamos usar mais não delete)

Agora é hora de configurar o arquivo “site.xml” que determina quais “paginas” serão criadas em nosso projeto, lembra do nosso amigo Gaia Site Creator? Então é hora de iniciar ele, com o Gaia Site Creator aberto importe o arquivo “site.xml” que se encontra dentro da pasta “bin>xml” o arquivo deve aparecer como na imagem abaixo:

Essa é a estrutura básica que o Gaia Framework cria para o projeto, porém, não é a estrutura que vamos usar para esse projeto inicial siga os próximos passos para configurar corretamente o arquivo “site.xml”
Clique no item “home” e no item “id:nav” e arraste eles para o campo vermelho chamado “drop here to delete” como mostra a figura abaixo:

Configurando um projeto de portfólio dentro do Gaia Site Creator

O item “id:index” funciona como uma “Main page” ele é o root do nosso aplicativo(existe ainda uma classe chamada “Main.as” mas vamos falar sobre ela depois. Nesse projeto todas as paginas serão filho da pagina “índex.fla”

Para criar um novo “filho” no arquivo “site.xml” você deve clicar na aba “assets” do Gaia Site Creator e arrastar o item “New Page” para dentro do item “id:index” e depois configurar algumas propriedades como mostra na figura abaixo:

1. Nome utilizado posteriormente para acessar essa pagina
2. Nome do arquivo swf que será criado quando o Gaia Framework for compilado
3. Titulo da “pagina” quando esse arquivo for acessado

A descrição para as outras configurações desse arquivo não serão abordadas nesse momento e podem ser encontradas nesse link

Antes que eu esqueça de dizer esse projeto vai ser um portfólio de um Flash Developer como eu e você então a estrutura de paginas vai ser como mostra a imagem abaixo:

1. Pagina de apresentação
2. Perfil do desenvolvedor
3. Portfólio
4. Fotos
5. Vídeos
6. Contato

A minha intenção com esse tutorial é que posteriormente eu mostre como trabalhar com algumas classes que utilizo então podemos explorar integrações com Twitter, Flickr, Youtube etc… Esse projeto vai servir como base para outros tutoriais.

Criada essa estrutura dentro do Gaia Site Creator clique na aba “file > Export > ExportSiteXML” e sobrescreva o arquivo “site.xml” com essa nova configuração, abra esse arquivo dentro do software Flash Develop (imagino que você já esteja utilizando ele para desenvolver seus projetos) a estrutura do arquivo “site.xml” ficou da seguinte forma:

Se você seguiu todos os passos que descrevi acima, abra novamente o Adobe Flash Cs5, com o painel do Gaia Framework aberto vá até a aba “scaffold” e clique em “scaffold project”.

Ele vai criar todos aqueles arquivos que configuramos no “site.xml” dentro da pasta de projeto, aguarde os arquivos serem criados/compilados, ao final desse processo ele vai abrir uma aplicação como na figura abaixo:

Agora no painel do Gaia Framework a aba que ficou marcada é “Publish” clique no botão “save” que fica no canto direito superior para salvar esse projeto. Agora na lista de projetos criados você tem todos os projetos que está trabalhando no Gaia Framework como mostra uma visão dos meus projetos na figura abaixo:

Clique duas vezes sobre o projeto que estamos trabalhando, vá até a aba “publish” clique na pasta “lib” e veja que todos os arquivos configurados no “site.xml” foram criados dentro do projeto como mostra a figura abaixo:

1. Esse botão deve ser usado sempre que você fizer alterações nos arquivos, não adianta apenas dar um CTRL+Enter no arquivo é preciso clicar nesse botão para compilar os arquivos marcados na lista, caso algum arquivo não esteja marcado ele NÃO vai compilar o arquivo
2. Botão abre a pasta raiz do projeto
3. Lista de arquivos do projeto
4. Esse botão sincroniza as modificações feitas no arquivo “site.xml” e vamos tratar disso nos próximos tutoriais

Clique no botão “Test Project” para ver o resultado desse tutorial, lembrando que essa tela preta que aparece é fruto de uma configuração inicial feita pelo Gaia Framework, se você abrir por exemplo a pagina “home.fla” não vai ver nenhum “asset” dentro dela ou da library, não se assuste vamos tratar desses e de outros assuntos no próximo tutorial.

Nesse tutorial não vamos abordar o desenvolvimento do menu do site, então para navegar no projeto feito até aqui utilize o botão direto do mouse e clique no ContextMenu para navegar entre as paginas.

Conclusão

Nesse tutorial eu abordei os aspectos básicos para desenvolver usando o Gaia Framework, veja que não fizemos nenhuma linha de código, mas não se engane existem muitas coisas para aprender ainda.

No próximo tutorial vou falar sobre a estrutura de pastas criadas pelo Gaia Framework e como iniciar nosso projeto com as modificações em Actionscript 3.0 ou seja, prepare-se para programar no próximo tutorial.

Arquivos utilizados no tutorial

Baixar

Resultado desse tutorial

Link

Meu perfil no Facebook
Meu Twitter

Uma abraço a todos, divulguem esse tutorial!

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?