Já está aberta a venda do livro jQuery Mobile na Prática. Por apenas R$ 10,00, você terá a chance de conhecer este framework do melhor jeito possÃvel, através de exemplos práticos!
O lançamento ocorrerá no dia 27/02.
Muitas surpresas estão por vir, aguarde!
http://www.danielschmitz.com.br/jquery-mobile-na-pratica.html
Veja mais neste post.
Ele mostra ainda em outro post que o Tour de Flex agora está disponÃvel para iPad.
O artigo Adobe Flex com PHP usando ZendAMF – primeiros passos teve como objetivo exemplificar a integração do Flex com PHP para quem já tinha sistemas desenvolvidos usando o AMFPHP, por isso não usei as classes para acesso a banco de dados do ZendFramework. Neste artigo mostrarei o mesmo exemplo mas usando exclusivamente ZendFramework.
Pegarei o mesmo exemplo utilizado no artigo anterior, só modificando a classe PHP para usar as classes de abstração de banco de dados do ZendFramework. Começaremos com nosso gateway.php
Executando o link no seu navegador, deve aparecer a seguinte mensagem:
Zend Amf Endpoint
Em seguida, modificaremos em nossa classe principal, que efetuará as operações de listar, inserir, apagar e atualizar os dados do nosso banco:
No ActionScript só precisaremos mudar o que será passado para o PHP, ao inves de VOs, mandaremos Arrays:
Referências:
http://framework.zend.com/manual/en/zend.db.adapter.html
Ontem, estava procurando uma ferramenta para desenhar diagramas, que me desse mais op??es de diagramas e fosse mais flexivel do que todas as demais ferramentas que j? havia utilizado at? o momento. Realizando uma busca no Google acabei encontrando a Cacoo.
Site | Google Chrome Web Store
At? o presente momento, utilizando a ferramenta, gostei da facilidade de uso e da quantidade de elementos gr?ficos dispon?veis para utilizar nos diagramas, est? atendendo bem a minha necessidade de cria??o de diagramas.
A última implementação da HibernateDAOFactory do módulo persist do DCF, agora permite que seus DAOs de entidade possuam propriedades injetadas diretamente do container de beans do Spring.
No exemplo que temos nos testes de projeto, temos o MockDAO, que possui uma propriedade String com nome ‘testeString’:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
public class MockDAO extends HibernateEntityDAO
private String testeString; public MockDAO(SessionFactory sessionFactory) @Override public String getTesteString() @Autowired |
Note que no setter da propriedade, colocamos a anotação @Autowired, para recuperar esta String do container, e também associamos o Qualifier ‘testeString’.
No arquivo de beans do spring, basta adicionarmos um bean String com o id igual ao do qualifier:
|
1
2 3 |
> |
Repare que o valor da String é ‘stringTeste’. Vamos ver em nosso teste agora se tal valor chega corretamente no DAO:
|
1
2 3 4 5 6 7 8 9 10 |
@Test
public void testRightFactory() MockDAO dao = this.getDaoFactory().getDAO(MockEntity.class); Assert.assertNotNull(dao); Assert.assertEquals(this.getDaoFactory(), dao.getDaoFactory()); Assert.assertNotNull(dao.getTesteString()); |
Uma coisa importante a se perceber, é que a chamada da DAOFactory permanece exatamente a mesma, mantendo assim a retro-compatibilidade com as outras versões, e apenas as injeções baseadas em anotações do Spring vão ser consideradas.
NÃO é necessário apontar o component-scan do Spring para o pacote de DAOs de sua aplicação. A injeção de beans adicionais é feita completamente a parte, seguindo o mesmo padrão de nome e de instanciação dos DAOs.
Qualquer dúvida, basta me procurar.
O projeto está no github, dentro do módulo persist do dclick-framework, ou diretamente no nexus da DClick.
Já que ultimamente estamos falando bastante de testes unitários, principalmente aqui na DClick, vamos revisar uma das ferramentas essenciais para executar essa tarefa: JUnit. Mais especificamente, vamos fazer alguns testes com o JUnit 4.8.1, que pode ser encontrado para download no site do projeto, ou até mesmo no repositório do maven.
A proposta desse post é apresentar a ferramenta para quem ainda não conhece, e relembrar ou até mesmo mostrar algumas funcionalidades muito úteis para nosso dia a dia de desenvolvimento.
Nas versões anteriores do JUnit, da 3.* pra baixo para ser mais exato, era necessário criar as classes de testes seguindo uma hierarquia pré-definida do JUnit para que os testes fossem executados. Era necessário extender uma das classes de Test Case do JUnit, e seus métodos precisavam seguir um padrão de nome especÃfico definido pelo framework.
Com a versão 4.* e a introdução ao suporte a Java 5, agora todas as configurações de testes unitários em JUnit são feitas via anotações, o que na minha opinião é muito mais rápido e fácil, tornando muito mais agradável e flexÃvel escrever testes unitários. Agora é possÃvel definir umahierarquia especÃfica para os testes do projeto, podendo abstrair muitas inicializações e padrões do sistema, facilitando o reaproveitamento e aumentando a velocidade de desenvolvimento. Afinal a maior parte do tempo gasto em desenvolvimento é com os testes.
Porém, com anotações, perdemos o acesso direto aos métodos de asserção de valores que as super classes definiam. A solução adotada foi tornar todos esses métodos estáticos e públicos, em uma classe especÃfica para guardá-los: org.junit.Assert.
Pode parecer uma solução não muito elegante do ponto de vista de código, e de fato não é quando consideramos código que será distribuÃdo e deploiado, porém é uma solução que faz total sentido no escopo dos testes unitários, tornando fácil o uso e acesso a tais funcionalidades.
Para testar nosso código, o JUnit fornece os métodos de assert. O conceito é muito simples, todo método de asserção recebe um valor que é o correto esperado pelo teste, e o outro valor que é o devolvido pelo seu código. A comparação é executada, e o teste falha caso sejam diferentes e passa caso sejam iguais. Apenas com esse conceito é possÃvel testar todo o código, basta saber quais são os valores que devem ser testados para garantir o funcionamento do código.
A chave para escrever um teste unitário que cobre muito bem o seu código, é colocar as asserções nos valores realmente relevantes ao funcionamento do sistema. Algumas vezes por exemplo, não é preciso testar um valor intermediário gerado pelo código, apenas o resultado final, outras vezes esse valor intermediário gerado é crucial para o resultado final, e portanto deve ser verificado também.
Quando eu menciono ‘valores’, entenda que um valor pode ser qualquer objeto Java, portanto é muito importante implementar o equals e hashcode de seus objetos de resposta que serão testados pelo JUnit.
Vamos criar um exemplo de classe de testes com o JUnit 4 para vermos como funciona na prática a execução de testes unitários.
Se você utiliza o Eclipse, você já possui instalado o plugin de execução de testes do JUnit, caso você não tenha tal plugin, recomendo que instale posi facilita muito a execução e depuração dos testes.
Vamos criar uma classe de testes:
|
1
2 3 |
public class JUnitTestCase
|
Repare que apesar do nome parecer que segue algum padrão, não é necessário que a classe tenha nenhuma dessas palavras em seu nome. Porém esta classe ainda não é uma classe de testes do JUnit. Para torná-la um teste, crie um método da seguinte forma:
|
1
2 3 4 |
@Test
public void metodoQualquer()
|
Repare na anotação org.junit.Test. Essa anotação diz que nosso método ‘metodoQualquer’ é um teste do JUnit. Perceba também que seu retorno é ‘void’ e ele não recebe nenhum argumento. Agora nossa classe é um teste propriamente dito. Simples assim. Vamos adicionar uma asserção agora para ver o funcionamento da mesma. Dentro do método que acabamos de criar, adicione a seguinte chamada:
|
1
|
Assert.assertEquals(“2 dividido por 2 deveria ser 1.”, 1, 2 / 2);
|
Repare que o primeiro argumento do método, é a mensagem que vai aparecer caso o método falhe. Mude o valor obtido (último argumento) para ver a mensagem de erro.
Esse é o básico de execução de testes. Por mais simples que possa parecer, esse é o ponto de partida. Agora existem outras funcionalidades qua ajudam a escrever testes mais complexos, por exemplo, se precisarmos criar um objeto mais complexo para nossos testes, fazemos o seguinte, adicione o seguinte código em nossa classe de testes:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
private String stringLocal;
@Before @Test @Test @After |
Rode o teste e veja o que aparece no console.
Repare que a String é inicializada e setada novamente pra ‘null’ 3 vezes. Isso porque nossa classe possui 3 métodos de testes, e os métodosanotados com @Before rodam sempre antes de todos os métodos de teste. O mesmo vale para os métodos anotados com @After, só que estes rodam depois de executar os métodos de teste.
Só com essas duas anotações é possÃvel criar cenários que estão sempre ‘zerados’ e corretamente incializados para cada teste que será executado em sua classe. Perceba que com isso é possÃvel separa melhor as asserções em suas classes em mais métodos, deixando mais especÃfico e focado cada método de teste.
Porém algumas vezes queremos inicializar algum objeto para o teste todo, sem precisar de algo especÃfico para cada execução. Nesse caso existem duas outras anotações que podem ser úteis. Adicione o seguinte trecho em nossa classe de testes:
|
1
2 3 4 5 6 7 8 9 |
Só existe um restrição com essa abordagem, e acho que está claro no código qual que é: o escopo dessas chamadas é estático. Repare que os métodos precisam ser estáticos, e portanto as incializações só servirão para propriedades que são estáticas em sua classe de testes.
Essa funcionalidade possui esse comportamento porque o JUnit instancia um novo objeto da sua classe de testes para cada método que será rodado, dessa forma ele garante um melhor isolamento dos testes, tornando-os mais unitários por assim dizer. Dessa forma somente métodos estáticos são garantia de execução antes de todos os outros métodos.
Rode o teste e veja a ordem das mensagens em seu console.
Essa foi uma introdução muito simples do JUnit e testes unitários. Acho que já passou pela sua cabeça muitas formas de inicializar, integrar e rodar testes em sua aplicação usando JUnit, o que é ótimo, mas ainda existem boas práticas para criar testes assim como existem boas práticas para escrever código, afinal testes são linhas de código também.
O segredo de um bom teste unitário é o quanto ele consegue cobrir do funcionamento do código, sem que seja necessário escrever um teste extremamente detalhado que deixe o código acoplado demais, e não permita muita mudança no código original. Se você investir tempo demais testando TODOS os valores possÃveis de suas classes de maneira extremamente detalhada, quando o cliente pedir que um requisito mude, você com certeza vai ter a sensação de trabalho jogado fora, e desânimo por ter que escrever tudo novamente. A idéia é utilizar padrões de design para testes unitários, de forma que se mantenha a cobertura de código no 85%+ e ainda deixe os testes bem flexÃveis a mudança. DifÃcil mas não impossÃvel, e sim, é muito mais difÃcil e trabalhosos escrever testes realmente bons, do que escrever o código que será testado.
Por @Gust4v0_H4xx0r
2012 será mais um ano de ascensão dos dispositivos mobile em todo o mundo. Mesmo que aqui no Brasil tudo seja mais lento, com preços mais altos, estamos seguindo em frente. Já temos frameworks javascript adaptados ? s telinhas, como o Sencha, ? e o jQueryMobile, além do Flex Mobile, claro. Outras tecnologias estão crescendo a cada dia, e a quantidade de informação que é “jogada” para nós programadores aumenta em um ritmo alucinante. Seguindo esta tendência, estamos também nos adaptando, e para que tudo fique bem claro ao leitor, decidi comentar as principais mudanças do site neste post.
Neste novo ano estaremos adotando algumas mudanças que visam melhorar a qualidade de nossas obras. As principais mudanças que estão por vir são:
1)? Fim do suporte por email: Nestes quatro anos de suporte por email, pude observar diversos prós e contras, e sempre tentei agradar a “gregos e troianos”. Nunca fiz nenhuma distinção de quem comprou ou quem não comprou meus livros, sempre respondendo as dúvidas em menos de 48 horas. Todo esse tempo foi um aprendizado enorme, e agora tenho a necessidade de “lapidar” este processo de suporte. Observei que muito das dúvidas dos leitores eram repetidas e que sempre respondia ? s mesmas questões. Observei também que, ? s vezes, dava prioridade a alguém que não tinha comprado um livro, e deixava “na fila” uma outra pessoa que tinha dúvidas relativas aos livros. Também cheguei ao ponto de responder 10, 15 e-mails por dia, tornando uma tarefa bastante trabalhosa. Neste contexto, estarei “movendo” o suporte para um fórum especial, aberto a qualquer pessoa e destinado a sanar dúvidas dos livros. Falarei mais deste fórum em um outro post, mas deixo claro que, para quem é leitor, terá como sempre o suporte 100% garantido.
2)? eBOOKs serão predominantes: Todo o processo de criação/distribuição de um ebook é perfeito aos olhos do autor se não fosse a pirataria. Realmente encontrar meus livros que consumiram várias horas de preparo e trabalho nos torrents por aà não é uma sensação boa. Mas eu quero acreditar que isso é possÃvel! Eu quero acreditar que o brasileiro é gente honesta, que deseja pagar por um conteúdo útil sem ser “assaltado”. Por isso, em 2012, eu vou priorizar o desenvolvimento de eBooks, cobrando um preço justo, e com a meta de criar muito mais ebooks do que já foi criado atualmente.
3)? Flex não será prioridade: Nestes últimos quatro anos tenho me dedicado muito ao Flex. Fui o primeiro a escrever um livro sobre Adobe Flex no Brasil e desde então foram quase 10 livros abordando o tema. Sei que está chegando o momento em que eu terei que “dissipar” o meu conhecimento para outras áreas, pois o tema Flex já está bastante difundido, felizmente hoje em dia existe bastante conteúdo dedicado a cultura Flex e só não aprende quem não quer. Veja que, para quem escreve livros, as tecnologias saturam, mas não morrem. Este é o caso do Flex, o conteúdo está saturado, eu não tenho muito mais a escrever, por isso o foco será distribuÃdo para outras áreas. O livro “Adobe Air em Ação” será o último livro a ser escrito para a tecnologia Flex, e não haverá mais edições previstas. O suporte continuará normalmente para quem comprou qualquer livro sobre Flex.
4)? Mobile será prioridade: Daremos certa prioridade ao desenvolvimento mobile, e dependendo de novas tecnologias que deverão surgir, estaremos pesquisando e publicando material sobre elas. Isso significa que determinados livros poderão conter menos páginas, por exemplo, 100, mas que expliquem um conceito ou tecnologia emergente.
5)? Tendências serão prioridade:? A rapidez com que uma tecnologia emerge abre uma lacuna de desinformação para nós tupiniquins. E a? idéia? é preencher esta lacuna com um livro. Por exemplo, ainda não temos um livro sobre SENSHA, muito menos EXTJS. Um livro sobre HTML 5, custa nada mais, nada menos que 73 reais. Nem temos um livro sobre a linguagem SCALA ou sobre DJANGO. Enfim, existe muito assunto para se escrever.
6)? Site flex.etc.br deixa de conter informações sobre os livros:? Todas as informações estarão no site danielschmitz.com.br. O blog flex continua, mas aos poucos deixará de ser atualizado.
Resumindo:
- Vamos publicar ebooks com qualidade e a preços atraentes, sobre diversos temas. Contamos com a aprovação de vocês, enviando crÃticas e sugestões, .
- Haverá um fórum dedicado ao suporte dos livros.
- Estaremos em breve publicando quais serão os primeiros eBooks a serem lançados e contamos com a sua opinião. Mande ideias !
Uma das vantagens de utilizar a arquitetura do Spring para implementar projetos Web, é fazer uso do Sprin-WEB-MVC. Quem já usou sabe que isso é uma vantagem a se considerar quando for feita a escolha das tecnologias e frameworks que serão utilizados no projeto.
Spring WEB-MVC é uma abstração poderosa para a camada de apresentação, tornando muito flexÃvel o uso de diferentes tipos de tecnologias no frnt-end da aplicação.
Veremos uma dessas abstrações que ajudam a modularizar e simplificar nosso trabalho do lado do servidor: Views.
Toda requisição que segue para o WEB-MVC passa pelo DispatcherServlet do spring. A partir daÃ, o container se responsabiliza por delegar a chamada para o controller correto, baseando-se nas configurações de sua aplicação.
Depois que a chamada é tratada pelo controller, o spring manda a resposta correspondente atrelada a uma View. Uma View é um descritor da forma com que os dados vão ser apresentados na interface, podendo ser JSP, JSF, JSon, XML, etc., ou até mesmo uma forma de encapsular os dados especÃfica da sua aplicação.
O poder das Views está justamente no fato de ser apenas uma descrição de como os dados serão apresentados, portanto desconecta-se completamente da aplicação, e pode ser aproveitada em outras ocasiões por outros sistemas.
Uma View no Spring nada mais é do que uma interface Java que descreve o tipo do conteúdo, e é responsável por renderizar a requisição:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 |
/*
* Copyright 2002-2008 the original author or authors. * * Licensed under the Apache License, Version 2.0 (the “License”); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an “AS IS” BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package org.springframework.web.servlet; import java.util.Map; import javax.servlet.http.HttpServletRequest; /** This class and the MVC approach associated with it is discussed in Chapter 12 of View implementations may differ widely. An obvious implementation would be Views should be beans. They are likely to be instantiated as beans by a ViewResolver. /** Note: This attribute is not required to be supported by all
/** Can be used to check the content type upfront, if not predetermined. /** The first step will be preparing the request: In the JSP case, in case of empty model) } |
Todo o código e JavaDoc está no projeto do Spring.
Vamos criar um exemplo de controller com duas views diferentes: JSon e XML. JSon e Xml são os formatos mais comuns na Web, por isso vamos ver uma das maneiras de devolvê-las em nossos contrllers.
Não vou entrar no detalhe de como configurar os controllers da sua aplicação para funcionar com o Spring-WEB-MVC, pois não é o intuito deste post, e existe bastante documentação disponÃvel na internet sobre o assunto.
A maneira que escolhi para o exemplo, foi deixar a resposta padrão da servlet como XML, e criar uma alternativa de view em JSon. Você pode configurar como quiser a ordem e o padrão de view da sua aplicação, essa escolha serve apenas para ilustar como lidar com os dois casos.
Comece criando alguma classe de domÃnio para servir de resposta do nosso controller:
|
1
2 3 4 5 6 7 8 9 10 |
Agora vamos criar um Controller para devolver nosso objeto de domÃnio:
|
1
2 3 4 5 6 7 8 9 10 11 12 |
@Controller
public class ExemploController @RequestMapping(“/exemplo/xml”) } |
Agora temos uma servlet que responderá por “
Vamos configurar agora nosso ‘empacotador’ de XML para torná-lo formato padrão da aplicação. No arquivo de beans do Spring crie os seguintes beans:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
class=“org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter”> > > > |
O que fizemos foi criar um “marshaller” de XML que usa o XStream para converter ‘de’ e ‘para’ XML. Também mapeamos nossa classe de domÃnio para o alias “exemplo”. Feito isso basta criar um bean que representa os conversores de mensagens do Spring, nesse caso ‘messageConverters’, e associar o conversor de XML nele.
Pronto! Agora que temos as configurações necessárias para criar XML, e anotamos nosso método do controller com ‘@ResponseBody’, o padrão do Spring será devolver o XML que representa a entidade de domÃnio criada:
|
1
2 3 |
> |
Para criar a view de JSon agora, vamos fazer de maneira diferente. Comece criando um bean em seu arquivo do Spring que representa a View de JSon:
|
1
2 3 |
class=“org.springframework.web.servlet.view.json.MappingJacksonJsonView”> > |
Note que precisamos da dependência do ‘Jackson’ no classpath do nosso projeto, que está disponÃvel no site do projeto ou até mesmo no repositório do maven.
Agora em nosso controler, vamos adicionar a dependência da view que acabamos de criar, e adicionar o método que tratará a requisição em JSon:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 |
Repare que não precisamos da anotação ‘@ResponseBody’, e que ao invés de devolver um ‘Exemplo’ estamos devolvendo o ModelAndView do SpringWEBMVC.
Para que a resposta chegue no formato correto, basta mandar a view de JSon que criamos junto com o ModelAndView, e o objeto de domÃnio. Dessa forma temos a resposta que esperamos:
|
1
2 3 4 |
“response”:
“nome”:”json” } |
Para a moda REST que está tomando força nos últimos tempos, as múltiplas views do Spring é uma ótima ferramenta para fazer parte dessa onda, e ainda prover diferentes maneiras de seu servidor se comunicar com diversos tipos de dispositivos e aplicações clientes, sem comprometer código com regras de negócio.
Espero ter sido útil, e qualquer dúvida, crÃtica ou comentário são sempre bem vindos.
Por @Gust4v0_H4xx0r
O Play ? um framework open source para aplica??es web, escrito em Java, que possibilita o desenvolvimento de aplica??es web que seguem o padr?o MVC. Tem por objetivo otimizar a produtividade do desenvolvedor atrav?s do uso de configura??o sobre conven??o (CoC). Com recompila??o feita durante a execu??o da aplica??o, e caso ocorra algum erro, o respectivo ? exibido no browser, indicando a linha do erro.
Aten??o: o objetivo desse post ? realizar uma vis?o geral do que se trat? o Play Framework que temos ouvidos os coment?rios na internet.
O Play Framework torna o desenvolvimento de aplica??es Java e Scala uma tarefa f?cil para o desenvolvedor.
Site: Play Framework
Descubra uma alternativa limpa e leve para as atuais aplica??es Java Enterprise. O Play ? focado na produtividade do desenvolvedor e tem por alvo a arquitetura RESTFul.
Apesar do Play ter sido escrito em Java, ele suporta a linguagem Scala desde a vers?o 1.1 (hoje[Dezembro/2011] est? na vers?o 1.2.4). Este ano a empresa Typesafe (respons?vel pela linguagem Scala), anunciou a aquisi??o do Play Framework e este ser? mantido pela empresa. Uma das novidades relacionado a este anuncio ? que a vers?o 2.0 o n?cleo do Play Framework est? sendo totalmente reescrito em Scala.
Um v?deo para uma breve apresenta??o do Play Framework: Desenvolcendo uma aplica??o web em 10 minutos
O Play foi muito inspirado no Ruby on Rails e Django. Um desenvolvedor familiarizado com qualquer um desses 2, ir? se sentir em casa.
Algo que ? fato, Ruby on Rails e Django s?o produtivos, ent?o por que n?o ter o mesmo n?vel de produtividade com java?
O Play utiliza do poder das aplica??es Java, por?m sem o “sofrimento” necess?rio para o desenvolvimento de aplica??es centradas no modelo Java Enterprise. Libertando das metodologias e ideologias relacionadas ao desenvolvimento de aplica??es Java EE, o Play prove para os desenvolvedores uma maneira f?cil e elegante de trabalhar, visando o aumento da produtividade.
Caso voc? queria, basta um editor de c?digo e ser? mais que o suficiente para o desenvolvimento de aplica??es, chega a ser incr?vel pensar que conseguiremos desenvolver aplica??es Java Web sem a necessidade de um IDE (Eclipse, Netbeans, …), mas vale lembrar, que estas IDE's ainda possuem seus atrat?vos e auxiliam em nossa produtividade.
Apesar de que as aplica??es desenvolvidas com o Play, foram projetadas para executar dentro do JBoss Netty Web Server, as aplica??es podem ser empacotadas em arquivos WAR e distribu?das para outros servidores de aplica??es Java EE (ex.: Apache Tomcat).
Stateless: o Play ? totalmente RESTful – n?o existe conex?o por sess?o Java EE. Isto torna o Play muito mais escal?vel que os demais frameworks.
Sem configura??o: realizar o download, descompactar e desenvolver.
F?cil ida e volta: sem necessidade de deploy no servidor de aplica??o, apenas edite o c?digo e atualize o browser.
Teste unit?rio integrado: suportes nativos para JUnit e Selenium.
API elegante: raramente um desenvolvedor ter? a necessidade de importar alguma lib. O Play j? disponibiliza a maioria dos recursos necess?rios para o desenvolvimento de uma aplica??o.
M?todos est?ticos: todos os controles de entrada e m?todos de neg?cio s?o declarados como est?ticos. E isto ? de fato bem diferente o que vemos nos demais frameworks Java.
I/O Ass?ncrona: atrav?s do uso do servidor web JBoss Netty, o Play consegue disponibilizar e tratar uma enorme quantidade de requisi??es ass?ncronas.
Arquitetura Modular: assim como Rail e Django, o Play utiliza o conceito de m?dulos. O que possibilida um meio elegante e simples de expandir o core do Play.
M?dulo CRUD: f?cil constru??o de UI administrativas com pouco c?digo.
M?dulo Scala: disponibiliza um suporte completo para Scala.
O Play utiliza massivamente algumas bibliotecas populares:
Funcionalidades presentes no n?cleo do Play:
Informa??es a mais da Wikipedia
Overview do Play Framework 1.2.4
Documenta??o Play Framework 1.2.4
A documenta??o foi algo que achei interessante, me parece bem completa com bastante exemplos e informa??es de como utilizar as funcionalidades presentes no Play Framework.
Suporte para a linguagem Scala
Utilize a IDE de sua prefer?ncia (Eclipse, Netbeans, …)
Se por um acaso voc? utilize o Sublime Text 2, veja esse suporte para este editor de c?digo [github]
Dentre eles temos: MongoDB, GAE, Gera??o de PDF, GWT, SASS e SCSS, entre outros.
Bom agora que j? temos uma boa id?ia do que se trata o Play Framework ? baixar e come?ar a testar e ver se na pr?tica ele ? bom mesmo.
Hora de fazer o download, instalar e colocar a m?o no c?digo: Tutorial para seguir e ver uma aplica??o do in?cio at? o “fim”
Eu particularmente ainda possuo algumas quest?es em aberto para descobrir as respostas, dentre elas est? uma: - Como ? que eu utilizo o Play Framework em um projeto com uma equipe? At? o momento s? tenho visto casos onde s?o apresentados desenvolvimetno de aplica??es r?pidas, por?m com um ?nico desenvolvedor…
No meu caso eu vou atr?s dessa reposta.
Olá pessoal, venho através desse post fazer um convite ? todos vocês.
Recentemente nós aqui do maranhão fundamos um adobe user group o BumbAUG (Bumba meu boi + AUG) e gostarÃamos de lhe convidar a fazer parte desse grupo.
Inicialmente nós iremos tratar principalmente o desenvolvimento de aplicações mobile sejam utilizando o flex, PhoneGap ou mesmo nativamente. Poderemos também fazer algo de introdução ao Flex Framework, mas isso é projeto futuro.
Apesar de ainda estar engatinhando nós do BumbAUG realizamos no dia 18/11 o Flash Mobile Day Edição São LuÃs, onde tivemos palestras das mais diversas áreas.
Acessem o grupo, participem, deixem suas idéias e contribuição. Como eu já falei é um GRUPO de estudos, então se você tiver um tema para palestrar, sinta-se ? vontade. O espaço é seu.
O Rafael Laranjeiras já marcou 2 palestras muito interessantes e em breve eu irei divulgar os temas para vocês.
Acessem: http://bumbaug.groups.adobe.com e vamos levar o desenvolvimento de aplicações ? um novo patamar.
