[size=18] [b]Waffle is built upon the following:[/b]
[/size]
* Simplicity
* Convention based approach (like Ruby on Rails)
* Components following Dependency Injection (DI) pattern
* No singletons
* No mandatory dependency on XML (and NOT annotation heavy)
* Java 5 and above
* Pluggable design for Waffle itself
* AJAX Ready
@ActionMethod(parameters = {"firstNumber", "secondNumber"})
public void multiply(float firstNumber, Float secondNumber) {
result = firstNumber * secondNumber;
}
}
Se for pra inovar, pq não consideram o nome dos parâmetros de forma convencional ao invés de ter que passar essa nháca dentro da anotação?
Edit: pensando bem, talvez causaria uma certa confusão em um possível refactor :lol:
Pra mim, just another web-framework
o waffle tem um relacionamento muito forte com o vraptor. se for ver, varias das ideias dos dois frameworks sao muito parecidas. ha ate um certo esforco em convergir algumas coisas, como a taglib deles.
e nao da pra pegar em runtime os nomes dos argumentos de metodos por que o compilador retira essas informacoes. por isso que, tanto no vraptor como no waffle, vc tem essa anotacao. ha quem prefira o paranamer tambem.
- Vraptor tem essa caracterista, também ? [size=18] ; )[/size]
Waffle provides built in support for Ruby, allowing you to easily write your controllers in Ruby. The integration is simple and straightforward, taking advantage of functionality Waffle provides (without the Rails!).
A key feature of Waffle has always been its pluggable architecture. From the beginning we believed that the default behavior defined by the Waffle team might not be suitable for every situation. Therefor Waffle was built following an Interface driven approach. Practically all of Waffle’s built-in functionality can easily be extended or replaced. This design made integrating Ruby support quite easy.
nao ha nada planejado para colocar ruby, mas como ele disse, por causa da arquitetura de plugins, coisas internas podem ser muito facilmente estendidas ou substituidas.
fazer o vraptor executar codigo ruby provavelmente seria trabalho de uma hora… só nao sei se isso eh realmente util 
[quote=Sergio Lopes]nao ha nada planejado para colocar ruby, mas como ele disse, por causa da arquitetura de plugins, coisas internas podem ser muito facilmente estendidas ou substituidas.
fazer o vraptor executar codigo ruby provavelmente seria trabalho de uma hora… só nao sei se isso eh realmente util :)[/quote]
- Será que o Fabio Kung teria melhor resposta ? Tô querendo fazer um curso de Ruby …[size=18]; )[/size]
Eu diria um pouco mais de uma hora. Não é tão simples quanto parece…
Ruby não é util?
Annotations e XML são ruins agora? Que novidade!!! :roll:
E usar uma classe central para configurar tudo em código Java eu tb nunca vi…
eu duvido que ele falara para implementar suporte a ruby no vraptor!
provavelmente ele vai falar pra voce usar rails ou merb logo de uma vez hehehe
é, talvez…
muito pelo contrario! tao util que acho que nao vale a pena tacar ideiais de um framework java pra ele…
se for usar ruby, use logo rails ou merb. é minha opiniao
Entendi o seu ponto. Mas Java tem algumas vantagens sobre Ruby. Plataforma madura, estável, IDE maravilhosa e produtiva (instale o ZeroTurnaround antes), Tomcat, Jetty, Resin.
Eu gosto de Ruby quando vc precisa de expressividade. Quando o algoritmo é complexo, com certeza Ruby ou Python são melhores soluções do que Java. Active Record também é uma sacada legal…
Agora a tipagem forte e o compile-as-you-type da IDE são funcionalidades do Java que a tornam bastante produtiva e a prova de erros. Sem falar em refactoring…
Um framework web Java com suporte total a Ruby é o melhor de ambos os mundos, na minha opinião.
Hummm !!! será Sergio Lopes !!! … [size=18]; )[/size]
JRuby é o elo para esses dois mundos ?
Sim. Já que o Java nunca vai ser melhor que o Ruby em certos aspectos, vamos trazer o Ruby todo para dentro da máquina virtual.
JRuby é o cara…
[quote=saoj]Entendi o seu ponto. Mas Java tem algumas vantagens sobre Ruby. Plataforma madura, estável, IDE maravilhosa e produtiva (instale o ZeroTurnaround antes), Tomcat, Jetty, Resin.
Eu gosto de Ruby quando vc precisa de expressividade. Quando o algoritmo é complexo, com certeza Ruby ou Python são melhores soluções do que Java. Active Record também é uma sacada legal…[/quote]
concordadíssimo! mas ai a solucao q prefiro é rodar um framework 100% ruby em cima da JVM, com Jetty etc
Todavia tais features não surgiram simplesmente atoa, assim torna-se possivel até mesmo uma adequação para frameworks que tem seu legado em Java, usando-se JRuby seria a extensão para essas adoções Full-Stack até mesmo para o VRaptor em uma versão Ruby, o Waffle já sai na frente também Convention based approach (like Ruby on Rails), abstração, metaprogramação.
Aprova de erros eu não arriscaria dizer. Já vi cada absurdo mesmo com tipagem estática que, deixa pra lá…
Concordo com o Sérgio que o melhor dos dois mundos mesmo é rodar um framework Ruby em uma JVM.
Se posso ter toda a expressividade e metaprogramação de Ruby + APIs Java master uteis e conceituadas, tudo rodando numa mesma JVM, não tenho necessidade alguma de um framework Java que faça uso de código Ruby.
A menos, é claro, que você já tenha uma aplicação completa feita em um framework Java e agora precise incorporar algum algoritmo, ou API, que será muito melhor escrito (ou já esteja escrito) em Ruby. Nesse caso, concordo que a programação poliglota seria bem interessante. Um amigo coisas interessante nesse sentido (veja aqui e aqui).
Mas esse não é o caso apenas de Ruby, mas de Javascript, Python, BeanShell, etc, afinal, esse não é o objetivo da Java Scripting API?
Agora, um framework Java que suporte Ruby apenas para dar a opção de você escrever tanto código Java quanto Ruby, por pura opção, não acho muito interessante não. (IMHO)
Aqui você defende uma idéia ao JRuby.
[quote]
Agora, um framework Java que suporte Ruby apenas para dar a opção de você escrever tanto código Java quanto Ruby, por pura opção, não acho muito interessante não. (IMHO)[/quote]
[b]Aqui você condena.
“Contraditório”[/b]
[quote=Marcio Duran]
“Contraditório”[/quote]
Acho que você não conseguiu contextualizar os paragrafos do meu post. Mas vamos lá…
1ª afirmação: Usar um framework Ruby rodando em uma JVM e fazer uso de APIs Java quando necessário.
2ª afirmação: É uma boa ter a possíbilidade de usar código Ruby em uma aplicação construida com framework Java, quando realmente houver a necessidade. A Java Scripting API é uma mão na roda quando é preciso fazer isso.
3ª afirmação: Ter um framework Java onde você vai codificar tudo em Ruby, não me parece uma boa opção. Mas essa é a “minha” opção. Ao “meu” ver, esse não é o melhor do dois mundos.
Entendeu? Não há contradição nenhuma. Apenas dei dois cenários que “ao meu ver” são distintos e valem a pena misturar as coisas.
Como ja vimos, desde o hibernate 1 voce pode configura-lo programaticamente. Nao que seja pratico.
Nao da pra fazer isso :(. nao da pra descobrir nome de parametro de metodo em runtime no java, infelizmente. Essa informacao nao fica no bytecode (a nao ser que a classe tenha sido compilada com todas as infos de debug, mas mesmo assim nao da pra pegar por pura reflection, veja o projeto paranamer).
Como acho que vc mesmo observou no passado, todo framework possui configuração programática, porque eventualmente código é chamado, seja de XML ou seja de Annotations. Mas não é disso que estamos falando.
Estamos falando de adotar, implementar, incentivar e documentar toda e qualquer tipo de configuração via código central (ApplicationManager.java), sem usar qualquer XML ou Anotação, e isso o Mentawai foi o primeiro framework web MVC a fazer em 2005. Se isso é maravilhoso ou não, prático ou não vai variar de pessoa para pessoa, mas na minha opinião foi um dos principais diferenciais do framework, além da sua característica full-stack.
Acho que o Waffle gostou dessa linha também, pois adotou o AbstractRegistar para configuração central, pelo menos das actions, o que poderia ser tranquilamente feito através de Annotations, como muitos outros frameworks fazem.
Rapaz, os únicos programadores que eu conheço que ainda cometem erros de tipos incompatíveis são os que ainda estão na faculdade.
Se checagem estática de código fizesse alguma diferença (ou ao menos deixasse o código mais seguro, o que não é verdade, já que em Java ainda é possível ter ClassCastExceptions) os programas não teriam bugs.
E vale lembrar mais uma vez que o primeiro refactoring browser foi escrito em Smalltalk.
:arrow: ClassCastExceptions ----->[i] “A versão da máquina virtual, não muda” [/i]:lol: :lol: :lol: