Programando para a web com Scala e VRaptor

 @Resource class UsersController(dao:UserDao, userInfo:UserInfo, result:Result, validator:Validator) { @Path(Array("/users/{user.login}")) def view(user:User) = dao.find(user.getLogin)
@Path(Array("/users")) def list = { result include("users",dao.listAll) } } 

Já fazendo uso da sintaxe mais reduzida, a declaração do construtor ficou bem mais enxuta, com os parâmetros automaticamente sendo disponibilizados como atributos do objeto. A mesma redução acontece na declaração do método view, onde o tipo de retorno é inferido automaticamente e, como o método só tem uma linha, podemos omitir a abertura das chaves. Sempre é válido lembrar que Scala é estaticamente tipado da mesma maneira que Java. Programando em alguma IDE com suporte a linguagem, podemos ver em tempo de compilação que esse método retornará um objeto do tipo User.

Depois que a lógica é executada, o VRaptor, seguindo a convenção, vai direcionar para o jsp responsável por exibir a  listagem. Poderiamos até usar os JSPs como camada de visualização para nossa aplicação, mas o problema seria ficar preso às restrições impostas pela Expression Language (EL) e ao uso das taglibs padrões do Java. Por exemplo, para exibir a listagem seria necessário uma java.util.Collection ou de um Array para que a tag foreach da JSTL funcione. Aqui há uma incompatibilidade pois as coleções do Scala foram implementadas do zero, sem nenhum vínculo com as coleções do Java. Outra incompatibilidade é em relação as classes de dominio, se estas forem criadas em Scala, por default não são criados getters no estilo Java e com isso não conseguimos chamar os métodos a partir dos JSPs.

Para explorar o poder do Scala na view, foi usado o Scalate, um projeto para camada de visualização focado em tirar proveito do melhor que a linguagem tem para oferecer. Abaixo segue a página de listagem dos usuarios implementada com Scalate:

O primeiro detalhe diferente para quem está acostumado com os JSPs é a necessidade de declarar as variáveis que estão disponíveis no request para serem usadas dentro da página. O Scalate transforma isso numa classe em Scala para que depois possa compilar o código para ser otimizado pela JVM, evitando o uso de reflection.

Outro ponto interessante é a sintaxe utilizada para executar os trechos dinâmicos. O Scalate vem com suporte a diversas engines de renderização. No exemplo, estamos utilizando a chamada SSP (Scala Server Pages), que tem sintaxe similar ao Velocity. Um exemplo foi o for realizado no código acima. Outro ponto interessante de ser notado é o seguinte trecho de código:

Para conseguir pegar a url relativa ao contexto nas páginas dentro de uma JSP, faríamos uso da tag <c:url>. Mas no SSP estamos chamando o método url a partir de uma String. O problema é que na String não existe o método url, e mesmo assim o código funciona: a idéia foi usar o poder de implicit methods para adicionar comportamentos em classes que já existem sem que necessariamente seja preciso alterá-las, como é o caso da classe String.

Para que o método url possa ser invocado através de uma String, seria necessário a importação da classe que contém essa extensão de comportamento. Mas, como declarar váriaveis não é algo comumente feito por programadores que utilizam JSP, o Scalate disponibiliza uma maneira de importar classes e disponibilizar helpers para as views, sem que seja preciso de fato declarar a importação na SSP. Para isso, o programador simplesmente cria uma classe chamada Boot em um pacote chamado scalate e a engine a carrega automaticamente. Abaixo o código:

Repare que, através do método importStatements, disponibilizamos classes para serem utilizadas em qualquer página que for ser escrita, sem a necessidade dos imports. No exemplo acima, disponibilizamos as classes do pacote model para todas SSPs, já que é bem comum fazermos uso dessas classes nas views.

Além disso, o  método string2PimpedJSTLCore responsável pela mágica do método url na classe String.  Aqui é definido um método que consegue instanciar um objeto do tipo PimpedJSTLCore para qualquer String que chame o método url. Dessa maneira é possível simular uma adição de comportamento numa classe previamente escrita sem que precisemos promover alguma alteração na original.

Para quem quer aventurar-se na mistura das linguagens, como pregado pelos programadores poliglotas, o VRaptor já conta com um plugin que contorna alguns detalhes dessa integração. Para quem pensa em fazer uma migração, todos os SSPs devem ser colocados dentro da pasta ssp, seguindo a mesma estrutura da pasta jsp convencionada pelo VRaptor.