Vraptor3 + Flex

A maneira mais simples é você usar o vraptor X flex com Json. No caso o vraptor retorna Json e seu flex acessa tranquilo.

@Remotable não existe mais no vraptor3, mas você pode usar algo assim:

public class UserController {

    private final Result result;

    public UserController () {
        this.result = result;
    }

    public void find() {
        List<User> userList = [...]
        result.use(Results.json()).from(userList).serialize();
    }

}

Para receber json de forma transparente eu já não sei bem, mas isso o Lucas pode responder. O máximo que consegui pensar é algo na URL.

para gerar json é do jeito que o garcia falou… consumir json ainda não está implementado no vraptor… vc vai ter que fazer requisições normais, passando seus parâmetros a partir do flex…

No trabalho estamos usando SPRING+BlazeDS+Spring+Flex. Recomendo, a coisa fica parecida com um RMI da vida, bem fácil de fazer, além de usar o protocolo amf, te poupando banda já que mandar binário é bem menos custoso que mandar um Json ou XML. Além disso, vc ganha também a convesão Obj Java ->Obj Flex.

se for usar a solução do spring dá pra fazer junto com o VRAptor, já que o vraptor roda dentro do spring…

Primeiramente, parabéns pelo VRaptor Lucas. Comecei a usá-lo 2 dias atrás e achei muito legal. Além da facilidade, vcs tiram dúvidas sobre ele aki no Fórum muito rápido, o que acredito que trás bastante credibilidade e confiança para que os desenvolvedores utilize o projeto.
Mas voltando ao assunto do tópico, no caso do Flex, não vejo vantagem em acrescentar o VRaptor na jogada, vc vê alguma? Usando Spring com seu suporte ao BlazeDS, mais o Blaze DS, mais o Hibernate, as coisas viram praticamente um CRUD. Vc encapsula suas RN nos Services, utiliza as DAOs para persistência. E como vc faz o mapeamento Obj Java-> Obj Flex, vc pode criar um SERVICE e DAO básicos que façam o CRUD de todas as classes, e o BlazeDS se encarrega de saber a classe correspondente na hora da transmissão dos dados. VC só precisaria criar classes extras extendendo essas qdo precisasse de algo mais elaborado do que um CRUD. E mesmo nesse caso, ainda daria para usar Named Queries, ai vc não precisaria realmente criar nada, só as queries mesmo.
Mas enfim, se alguém tiver uma opinão diferente, gostaria de ler, pois o assunto me interessa.

Espero ter contribuido.

renzonuccitelli:

Mas voltando ao assunto do tópico, no caso do Flex, não vejo vantagem em acrescentar o VRaptor na jogada, vc vê alguma? Usando Spring com seu suporte ao BlazeDS, mais o Blaze DS, mais o Hibernate, as coisas viram praticamente um CRUD.

Ola Renzo

Voce tem razao. O BlazeDS vai bem mais direto caso voce so use Flex. Queremos que o VRaptor de suporte ao BlzeDS de maneira que voce possa compartilhar os componentes VRaptor que tenha criado. Dessa forma, caso voce tenha uma aplicacao que nao é puramente flex, pode trabalahr com flex E html puro de maneira simples se usar o VRaptor. Temos algumas dessas features planejadas para o 3.2, e se voce quiser dar sugestoes de features como essa, seria de grande valia para nos!

Abracos

Paulo Silveira:

renzonuccitelli:

Mas voltando ao assunto do tópico, no caso do Flex, não vejo vantagem em acrescentar o VRaptor na jogada, vc vê alguma? Usando Spring com seu suporte ao BlazeDS, mais o Blaze DS, mais o Hibernate, as coisas viram praticamente um CRUD.

Ola Renzo

Voce tem razao. O BlazeDS vai bem mais direto caso voce so use Flex. Queremos que o VRaptor de suporte ao BlzeDS de maneira que voce possa compartilhar os componentes VRaptor que tenha criado. Dessa forma, caso voce tenha uma aplicacao que nao é puramente flex, pode trabalahr com flex E html puro de maneira simples se usar o VRaptor. Temos algumas dessas features planejadas para o 3.2, e se voce quiser dar sugestoes de features como essa, seria de grande valia para nos!

Abracos

Olá Paulo,

Realmente onde estou trabalhando estamos mexendo apenas com Flex (na realidade com o air, mas pro server side dá no mesmo).
Um enorme problema que passamos, e muitos desenvolvedores Java + Flex que usam o Spring+BlazeDS e o maldito LazyInitialization Exception do Hibernate. Na hora de serializar via BlazeDS sua classe, a sessão com o banco está encerrada, aí fica uma m… Workaround horrível é que todas nossas entidades estão Eager, até a gente encontrar uma solução melhor (se vcs fizesse isso no VRaptor, seria perfeito…hehe). Achamos um outro workaround, mas sinceramente, usar uma versão alterada de Hibernate me da calafrios…rs. Uma alternativa seria crar uma anotação estilo @Transient para que esse erro não acontece, fica a sugestão e se vcs fizerem isso, acredito que muita gente que está trabalhando com Flex/Air vai usar o VRaptor.
Outra coisa chata é ter que ficar anotando minhas classes em Flex dizendo a qual classe Java ela se refere. Seria muito bom ter um CoC de forma que classes Java e Flex com mesmo nome não precisassem ser mapeadas, simplesmente já soubessem pelo nome quem são suas correspondentes. sempre usamos os mesmo nomes, ai na hora de refatorar, temos que mudar a classe Java, classe Flex e também a anotação no Flex. Sugiro tb não usarem o famigerado XML para fazer o mapeamento, o Spring+ BlazeDS não usa e isso é muito bom.
O BlazeDS também não suporta o rmtp, somente o LiveCycle, que custa os olhos da cara. Dizem que esse protocolo é excelente para fazer streamming de videos, bem como fazer aplicações de chat sem fazer pooling. Assim, eu tinha dado uma pesquisada em outras alternativas, e encontrei o Red5. Assim como ele, há outros aplicativos free que suportam rtmp, mas realmente ainda não cheguei a testar pra dar uma opinião sobre o assunto.
Também tinha pensado realmente na vantagem para quem quer trabalhar com Flex e também HTML puro. Nesse caso, seria muito bom mesmo.
Enfim, espero ter contribuído, precisando de algo

Boa noite,
Comecei a usar o Vraptor a pouco tempo e digo: “Esse é um ótimo framework e fica melhor a cada versão”.
Parabens pela iniciativa.

A respeito do Vraptor3 + Flex

Pelo que percebi, pode ser feita de maneira mais tranquila com Json ou BlazeDS (agradeço as sugestões). No entanto, acabei de ver no site da Adobe que existe a possibilidade de se consumir um WebService qualquer em ActionScript, ou seja, posso me comunicar com o Java através de WebService.

Creio que WebService seja a melhor maneira de se comunicar com plataformas diferentes, ou sera que não ?

WebService Flex http://livedocs.adobe.com/flex/2/langref/mx/rpc/soap/mxml/WebService.html

Com WebService dá sim, mas se kiser pegar o pessoal que mexe com flex, BlazeDS ou outro Data Service será mais interessante. Primeiro que ele faz o mapeamento das classes, coisa q o webservice não faz e vc vai ter que ficar parseando xml.
Segundo que o AMF transmite bytecode, então fica bem mais eficiente, consumindo menos banda. Tem um site bacana que faz um benchmark sobre as formas de comunicação.
Dadas as facilidades do Flex, uma opção seria tb fazer uma ferramente em Action Script pra parsear o xml direto para os Objetos Flex, no estilo do XStream

Não sei se é por que a vida toda eu trabalhei em projetos distribuídos, mas para mim essa idéia de largar as entidades persistentes na apresentação não me soa bem. Quando você usa os tão mal compreendido DTOs especificos para cada situação você não tem esse problema do lazy-load. Você carrega apenas o que você precisa e ainda facilita as devidas transformações antes de jogar os beans para a apresentação.

Minha opinião, é claro, mas o lugar das entidades é na camada de persistência. Um grande exemplo que dou é no caso da entidade User. Ela obviamente tem um campo de senha para que você precise autenticar. Então na camada de negócio você tem um método authenticate e faz a autenticação. Mas e aí, você vai devolver nesse método a entidade User? Mas essa entidade tem dados como senha e outras informações sensíveis, e não será legal você ter isso na apresentação. Se você serializar esse objeto vocẽ terá todos os dados do usuário exposto. Como te disse, talvez por ter trabalhado a vida inteira com projetos distribuídos sempre tive a visão de que dados sensíveis não podem sair da camada de negócio.

O que é o correto? Ter um DTO específico para as ações que você precisa, obviamente cuidando para reaproveitas os DTOs conforme o contexto. No caso acima eu criaria um DTO UserAuthenticated apenas com os campos que preciso e suas devidas transformações.

Até porque se você analizar uma aplicação FLEX + Java não deixa de ser uma aplicação distribuída. E obvio, é apenas uma opinião minha; e quem sabe isso pode te ajudar.

Abraços

garcia-jj:

Não sei se é por que a vida toda eu trabalhei em projetos distribuídos, mas para mim essa idéia de largar as entidades persistentes na apresentação não me soa bem. Quando você usa os tão mal compreendido DTOs especificos para cada situação você não tem esse problema do lazy-load. Você carrega apenas o que você precisa e ainda facilita as devidas transformações antes de jogar os beans para a apresentação.

Minha opinião, é claro, mas o lugar das entidades é na camada de persistência. Um grande exemplo que dou é no caso da entidade User. Ela obviamente tem um campo de senha para que você precise autenticar. Então na camada de negócio você tem um método authenticate e faz a autenticação. Mas e aí, você vai devolver nesse método a entidade User? Mas essa entidade tem dados como senha e outras informações sensíveis, e não será legal você ter isso na apresentação. Se você serializar esse objeto vocẽ terá todos os dados do usuário exposto. Como te disse, talvez por ter trabalhado a vida inteira com projetos distribuídos sempre tive a visão de que dados sensíveis não podem sair da camada de negócio.

O que é o correto? Ter um DTO específico para as ações que você precisa, obviamente cuidando para reaproveitas os DTOs conforme o contexto. No caso acima eu criaria um DTO UserAuthenticated apenas com os campos que preciso e suas devidas transformações.

Até porque se você analizar uma aplicação FLEX + Java não deixa de ser uma aplicação distribuída. E obvio, é apenas uma opinião minha; e quem sabe isso pode te ajudar.

Abraços

Olá garcia-jj

Realmente uma camada extra de DTO também foi levada em consideração para nosso problema de Lazy load. O fato é que na empresa o programa só conversa em https, então “não seria problema” transitar com a senha. Além disso, o mapeamento Java -> Flex não precisa ter 100% dos atributos, o BlazeDS só faz o match dos atributos que constam nos dois lados. Então, no nosso caso, acrescentar uma camada extra seria um saco, pois na hora de uma refatoração no domínio, seria necessário alterar a camada DTO também, e olha que mudar as coisas na camada Java e na Flex já é chato.
Mas em um projeto web comum, uma camada extra de DTO seria uma boa.
Eu tb pensaria em fazer com o webservice, e fazer um parser para objetos do Flex. Acessar atributos é bem fácil na linguagem e seria bem trivial fazer algo automático. Inclusive já usei essa idéia para fazer um minifrawork em Flex parecido com o SwingBean e lógica é bem parecida, daria para fazer um CoC bem com a cara do VRaptor. Vou ver se faço um swc pra isso e posto aki.

Na verdade não é pelo fato de você transitar a senha por http ou https. Mas sim por disponibilizar esse campo em qualquer lugar. Enfim, como eu te disse, talvez por eu sempre trabalhar com projetos grandes acabo tendo essa visão, hehe.

Mas webservices é uma boa. Se você usa EJB pode facilmente criar os webservices e exportá-lo. O pouco que conheço de flex foi quando criei uma ferramenta de testes automatizados baseado no selenium, mas se não me engano ele se comunica com SOAP.

Pois é, mas como eu te disse, vc não precisa te um campos senha no seu obj no Flex. Mas eu concordo com vc, também preferia usar o DTO, mas fui voto vencido na decisão…hehe.
Fizeram um framework no estilo do Selenium lá na empresa ficou bem legal, bena que não é aberto.