Primeiros passos com a especificação do MVC 1.0

Temos participado da especificação do MVC 1.0, uma das mais esperadas para o Java EE 8. Já há uma versão inicial para download. Você pode baixar sua especificação e API diretamente pela página do JCP, ou via maven, para o caso da API:

<dependency>
     <groupId>javax.mvc</groupId>
     <artifactId>javax.mvc-api</artifactId>
     <version>1.0-edr1</version>
 </dependency>

Vale ressaltar que a ideia dessa especificação não é substituir o JSF, que é um modelo de MVC baseado em componentes (component-based). Diferente disso, o MVC 1.0 propoe suporte para um framework MVC baseado em ações (action-based), assim como o VRaptor, Spring MVC e outros.

Integração com outras specs

A API do MVC se integra com diversas especificações do Java EE, como CDI, Bean Validation, e JAX-RS (The Java API for RESTful Web Services), sendo a última utilizada como base dessa nova spec. Na prática, isso significa que todo controller do MVC é um resource do JAX-RS e, por esse motivo, curiosamente podemos definir a anotação @Controller no escopo do método:

@Path("usuarios")
public class UsuarioController {

	@Controller 
	@GET
	public String lista() {
		// ...
	}
}

Interessante, não é? Com isso podemos ter classes hibridas, onde alguns métodos são controllers do MVC e outros serviços do JAX-RS. Mas claro, você também pode adicionar a anotação no escopo da classe, definindo assim que todos os seus métodos serão controllers.

@Path("usuarios")
@Controller 
public class UsuarioController {
	// ...
}

Ozark, a implementação de referência

A implementação de referência dessa nova especificação é o Ozark, que também já possui uma versão para download disponível via maven e pode ser testado com um nightly build do Glassfish.

<dependency>
    <groupId>com.oracle.ozark</groupId>
    <artifactId>ozark</artifactId>
    <version>1.0.0-m01</version>
    <scope>compile</scope>
</dependency>

Para facilitar esse setup inicial, também foi disponibilizada uma imagem de Docker que já inclui o Ozark, Glassfish e todos os seus exemplos.

Conhecendo um pouco do código

É assim que se parece um primeiro exemplo do MVC com Ozark:

@Controller 
@Path("olaMundoMVC")
public class PrimeiroController {

	@GET
	public String olaMundo() {
		return "olaMundo.jsp";
	}
}

Neste caso, o método olaMundo poderá ser acessado pela URL http://localhost:8080/projeto/olaMundoMVC. Após executá-lo, o Ozark despachará a requisição para a jsp de seu retorno, olaMundo.jsp, que deve estar presente em /WEB-INF/views/.

Além do retorno do método, existem diversas variações para definição da view que deve ser renderizada. Retornar um Viewable ou anotar o método com @View são algumas delas.

@GET
public String olaMundo() {
	return "olaMundo.jsp";
}

@GET
public Viewable olaMundo() {
	return new Viewable("olaMundo.jsp");
}

@GET 
@View("olaMundo.jsp")
public void olaMundo() {
}

Você encontra esse e diversos outros exemplos de uso do MVC em um mirror de seu repositório no Github, criado e atualizado para facilitar a navegação do código.

https://github.com/spericas/ozark/tree/master/test

Trabalhando com diferentes tipos de view

Além do JSP e Facelets, que são as definições de view do Java EE, o Ozark também oferece uma serie extensões que possibilitam integração com os mais diferentes tipos de mecanismos de template existentes no mercado. FreeMarker, Velocity, Mustache, Handlebars e Thymeleaf são algumas das possibilidades atuais.

Para utilizar o Mustache, por exemplo, você só precisa adicionar a dependência do ozark-mustache em seu classpath e pronto!

<dependency>
    <groupId>com.oracle.ozark.ext</groupId>
    <artifactId>ozark-mustache</artifactId>
    <version>1.0.0-m01</version>
    <scope>compile</scope>
</dependency>

Conveniente, não é? Nenhuma configuração adicional será necessária. Com isso você já poderá retornar views com a extensão .mustache nos métodos de seu controller:

@Path("mustache")
@Controller
public class MustacheController {

    @GET
    public String hello() {
        return "hello.mustache";
    }
}

Claro, muito além das que já estão implementadas, você pode usar qualquer tecnologia de view desenvolvendo sua própria implementação de ViewEngine. Veja aqui como a MustacheViewEngine foi desenvolvida.

Como contribuir

É importante lembrar que esse é um trabalho em progresso e que está em estágio inicial, mas desde já você pode contribuir enviando ideias, sugestões, dúvidas e críticas. Todos serão importantíssimos para definirmos o futuro do MVC do Java EE 8. Seu feedback pode ser postado aqui, ou enviado diretamente na lista de usuários users@mvc-spec.java.net.

Tags: , , , ,

38 Comentários

  1. Rafael Ponte 07/04/2015 at 10:07 #

    oi Turini,

    Excelente post! Muito bom ver a evolução da spec, principalmente porque agora teremos uma segunda opção no Java EE.

    Porem uma dúvida, como está a adoção do Covention Over Configurarion da spec? Estão seguindo as do JAX-RS ou criaram as próprias?

    Um abraço e parabéns pelo post!

  2. Rodrigo Turini 07/04/2015 at 10:49 #

    Oi Rafael! Um pouco dos dois, na verdade. Algumas convenções já estão sendo adotadas no MVC, como por exemplo o @Produces("text/html") ser default — no primeiro draft era obrigatório anotar a classe ou todos os métodos do controller com ele. Existe uma issue no JIRA da spec com algumas sugestões minhas, para atacarmos mais pontos. E boa parte das convenções serão aplicadas no JAX-RS sim, influênciando as duas specs.

  3. Lucas Pérez 07/04/2015 at 10:49 #

    A implementação de referência poderia ser o Vraptor 4…

    Faria bastante sentido, pois tudo (ou quase tudo) que está na Spec já tem no Vraptor há bastante tempo !!!

    Turini, Parabéns pelo Post !!!

  4. Fernando Moraes 07/04/2015 at 11:24 #

    Bacana! Estou acompanhando a spec, e oque me chamou a atenção foi sua simplicidade.

  5. Rodrigo Turini 07/04/2015 at 11:26 #

    Seria legal, né Lucas? Pena que por N motivos (e muita burocracia) isso é quase impossível, mas podemos e teremos sim uma implementação nossa =)

  6. Rafael Guerreiro 07/04/2015 at 14:05 #

    Excelente post e spec!

    Só alguns detalhes:

    – É sempre necessário informar a JSP que vai ser usada? (ou outro tipo de view)
    Não seria o caso de ter uma convenção, que nem o VRaptor, o nome do controller junto com o nome do método?

    – O Path também poderia seguir esse padrão: “/controller/method”.

    – No caso das várias formas de view, eu, por exemplo, poderia definir uma default padrão como o “.mustache” e ele já assumiria qual é o arquivo. Outra forma seria permitir a criação de custom anotations que já traduziriam a view correta, algo como:
    “`
    @GET(“myPath”)
    @Jsp
    public void action() // procura por controller/action.jsp

    @GET(“myPath”)
    @MyCustomView
    public void action() // procura pelo arquivo definido pela classe que interpreta essa annotation.
    “`
    Essa classe poderia ter um método mais ou menos assim:
    “`
    public String convert(Method m) // Já sabemos que esse método está anotado com @MyCustomView
    “`

  7. Eduardo 07/04/2015 at 19:55 #

    Olá Rodrigo só uma dúvida, essa versão do MVC 1.o, Já tem suporte com apache tomcat ou por enquanto só no glassfish?

    Obrigado, e parabéns pelo post.

  8. Rodrigo Turini 07/04/2015 at 20:17 #

    Oi Rafael! Essas convenções do VRaptor serão sim consideradas na spec, mas por enquanto estamos focando na construção do básico, da arquitetura da API, pra depois discutir e atacar esses outros pontos. Muitos deles precisarão ser implementados no JAX-RS, muita coisa ainda pode mudar no código e etc, por isso decidimos deixar o CoC um pouco mais à frente. Voltarei a escrever sobre isso aqui no blog assim que estivermos decidindo as convenções, pois com toda certeza precisaremos de muitas ideias e feedbacks.

  9. Rodrigo Turini 07/04/2015 at 20:18 #

    É possível sim, Eduardo! Ainda é um pouco trabalhoso, já que você vai precisar adicionar e configurar o CDI, JAX-RS e etc, mas testamos e funciona muito bem.

  10. Denis Góis 07/04/2015 at 22:15 #

    Não tinha lido Nada sobre essay nova spec ainda, excelente artigo. Vou acompanhar o desenvolvimento!

  11. Rodrigo Turini 07/04/2015 at 22:56 #

    Obrigado Denis! Fique de olho aqui no blog, sempre vamos postar novidades do MVC.

  12. Lucas Pérez 08/04/2015 at 11:01 #

    Turini,

    Uma pena mesmo!!! Isso ainda é uma coisa ruim nesse universo Java. Em outras linguagens esse processo é menos burocrático e bem mais ágil!!!

    Estamos na torcida!!! Podemos até criar uma campanha no twiter rs

    Parabéns pelo post novamente !!!

  13. Rodrigo Ferreira 08/04/2015 at 13:31 #

    Show de bola Turini!
    A spec está ficando bacana.
    Bom que tem você participando para dar os “pitacos” afim de torná-la o mais simples possível, similar a como é o VRaptor hoje.

    Parabéns!

  14. Cácio Costa 08/04/2015 at 20:09 #

    Poutz, era só dar Ctrl+C e Ctrl-V no VRaptor! Umas coisas que acho que deveria ter:
    – forward e o redirect estilo Result.redirectTo(this).algumaLogica(), pois é bem mais fácil de refatorar e não fica retornando String;
    – flash scope automático para os atributos de request;
    – adotar a convenção para pegar os parametros do request de acordo com o nome do parâmetro no método, pra não precisar ficar anotando os parâmetros da lógica.

    Vai vir a spec mas não vou largar do VRaptor! =D

  15. Rodrigo Turini 08/04/2015 at 20:17 #

    Concordo com os pontos que você sugeriu, Cácio! Ainda não temos forward implementado, mas o redirect provisório funciona com uma String feiosa — por enquanto. Essa parte da API ainda não entrou em discussão, mas com certeza assim que entrar vou insistir o estilo type safe do VRaptor

  16. Christian 08/04/2015 at 22:19 #

    Gostei, acho que esta ficando bem legal. Interessante a parte de classes hibridas.

  17. Nykolas Lima 08/04/2015 at 22:54 #

    É um pouco triste ver o quão conservadores são o pessoal da Oracle/Outras grandes que participam da JSR. No momento em que se pode definir um jeito melhor de se fazer as coisas, ainda vão para o lado conservador.

    Imagino o quanto você e o Guilherme insistem em funcionalidades que façam as coisas de uma maneira mais inteligente (convenções, esses retornar bizarros de string).

    Para falar a verdade, torço para que eles cedam um pouco e tentem ver as coisas por um lado diferente, mas tenho pouca confiança que isso vá acontecer.

    De qualquer maneira, parabéns pelo seu trabalho e esforço, estou na torcida!

  18. Rodrigo Turini 09/04/2015 at 00:47 #

    Verdade, Nykolas! Eles são MUITO conservadores, em varios sentidos. O que ajuda um pouco é que outras pessoas do expert group dessa spec também gostam de CoC e coisas do tipo, então acabam ajudando a fortalecer o argumento. Água mole em pedra dura, tanto bate até que fura! =)

  19. Odilio Noronha Filho 09/04/2015 at 15:04 #

    Parabéns, está ficando bem legal a spec, espero que tenha uma boa aceitação, até hoje mantenho projetos usando o playframework 1.x porque foi o que achei de mais prático no universo java até então, mesmo estando bem defasado em termos de updates, espero que em cima dessa nova spec surjam grandes projetos!

  20. Rogerio Coli 11/04/2015 at 09:01 #

    Rodrigo parabéns pelo Post. Uma dúvida que me ocorreu é em relação aos Frameworks Action Based. Pelo que entendi, boa parte das funcionalidades deles já estariam disponíveis na nova especificação, inclusive um dos principais recursos que justificam a escolha desse tipo de ferramenta, o CDI. Será que isso seria o início do fim de gigantes como o Spring ou o VRaptor? Ou Eles teriam que se reinventar?

  21. Rodrigo Turini 11/04/2015 at 20:26 #

    Oi Rogerio, obrigado! É isso mesmo, ele vai virar bastante o jogo para os outros frameworks, mas não acho que isso será o fim dos demais, assim como JPA não foi o fim do hibernate puro e etc. Sempre vai ter quem prefira usar a spec, e quem prefira usar outras implementações — que talvez terão um pouco mais de liberdade pra inovar e oferecer possibilidades que a spec não oferecerá. Bem, essa é a minha impressão… o que vocês acham?

  22. Glauber 12/04/2015 at 10:39 #

    Rodrigo, acho que deve-se pensar também em facilitadores na camada de apresentação para o MVC 1.0. Uma das coisas que mais sinto falta nos frameworks’s action based são tag libraries na camada de apresentação que facilitem a vida para trabalhar com ajax. No JSF temos dezenas destas tags que deixam bem fácil invocar um método via ajax e atualizar um determinado div ou região da página, ou trabalhar com push e poll. Outro aspecto a ser considerado é quanto a engine de template. O Facelets é simplesmente fantástico, seria excelente ter um engine de template semelhante ao Facelets.

  23. Rodrigo Turini 13/04/2015 at 09:54 #

    Oi Glauber, não poderia concordar mais! E vai bem além do ajax, né? Em Java, no geral, sinto bastante falta de componentes de view. O JSF adianta bem esse caminho, mas é algo bem específico pro modelo dele. Infelizmente (ou felizmente) a spec do MVC não vai focar em nada direcionado pra view, fora a integração com os principais templates que comentei nesse post.

  24. Leandro 13/04/2015 at 19:31 #

    Como ficaria a questão da localização das views no caso de um projeto web do maven, que por padrão utilizada outra pasta (src/main/webapp) para armazenar as views invés de (/WEB-INF/views/)?

  25. Rodrigo Turini 13/04/2015 at 22:18 #

    Oi Leandro, boa pergunta! O /WEB-INF/views/ é o local padrão, mas isso pode ser configurado via javax.ws.rs.core.Configuration do JAX-RS. Você pode ver essa configuração na interface ViewEngine.

  26. Rogerio J. Gentil 14/04/2015 at 17:39 #

    Excelente artigo e excelentes comentários. Esclareceram todas as minhas dúvidas…

  27. Rodrigo Turini 15/04/2015 at 01:01 #

    Que bom que gostou, Rogério! Em breve pretendo postar outro, entrando um pouco mais a fundo nos detalhes e implementação da spec.

  28. Rodrigo Turini 17/04/2015 at 12:19 #

    Oi pessoal, atualizando aqui, o Toshiaki Maki criou um archtype do maven para um projeto em branco já configurado pro MVC 1.0:

    https://github.com/making/mvc-1.0-blank

  29. Igor Dutra 01/05/2015 at 11:28 #

    Rodrigo, excelente post…

    Eu desconhecia o trabalho acerca da especificação do MVC 1.0, agora irei acompanhar bem de perto, muito do que foi citado/mostrado é familiar para aqueles que utilizam o Vraptor-4.

  30. jonas 05/05/2015 at 21:50 #

    Rodrigo obrigado pelo post, muito bom os comentários.

    Rodrigo se a nova spec ficar “parecida” com o que Vraptor já nos oferece, vocês fariam a implementação da
    spec e o Vraptor seria uma implementação dessa spec, ou o Vraptor continuaria mesmo como uma
    implementação independente perde mercado ?

  31. Rodrigo Turini 06/05/2015 at 09:45 #

    Obrigado, Igor e Jonas! Quanto ao VRaptor ser uma implementação da spec, ainda estamos estudando todas as possibilidades, mas com certeza a versão “pura” continuará existindo. Da mesma forma que existe o hibernate, sem JPA.

  32. Diego 24/03/2016 at 09:44 #

    Olá Rodrigo,
    ótimo post sobre a espec.
    Tem novas notícias sobre ela?

  33. Rodrigo Turini 24/03/2016 at 13:49 #

    Oi Diego, muito obrigado! Tem sim, em breve saí do forno um novo post com todas as atualizações

  34. Fernando Almeida 17/11/2016 at 17:56 #

    Dropped :/ Mas que coisa…

  35. Giuliano 22/12/2016 at 15:39 #

    Muito bacana o Post,
    Volta e meia tenho procurado mais informações sobre o Ozark e o MVC mas nada de novo encontro… como anda o projeto? está firme e forte?
    Até mais

  36. Rodrigo Turini 22/12/2016 at 16:29 #

    Oi Giuliano

    depois da reviravolta da Oracle, que decidiu fazer o Java EE 8 focado em cloud e microservices, o projeto ficou fora da lista de specs oficiais que vão entrar.

    A Oracle está estudando a ideia de “doar” o projeto para comunidade continuar.

    Assim que tiver mais informações sobre isso eu compartilho por aqui

Deixe uma resposta