[quote=saoj]
Não chamei ele de maluco. Tente ler mais uma vez o texto.
E fique tranquilo que tenho vergonha na cara sim.[/quote]
Você deixa a entender que ele tá ferindo com o conceito de liberdade, e manda essa:
Se você fizer um pouquinho de interpretação de texto, verá que indiretamente chamou ele de maluco 
Se ele se considera um interventor, uma pessoa que pode dizer o que pode ser feito, como e quando, então a carapuça vai servir. Mas sinceramente não acredito que seja o caso do Neal Ford.
[quote] Assim é a evolução, um passo de cada vez e os saltos são em tempos espaçados. Quando estes acontecem, vemos iniciativas como RoR , Hibernate (citados); batendo à porta. Os conceitos são introduzidos aos poucos, alguns
experimentos são testados e a adaptação dos “seres” se dá em meio às necessidades : Negócio, Time-to-marketing, que deveremos responder. [/quote]
Se não há um passo para frente, será que vale a pena investir tempo na criação de um novo framework que soluciona, do mesmo jeito, os mesmos problemas?
Com certeza, se houvessem apenas 2 ou 3 Frameworks, seria muito mais fácil escolher a melhor solução para o seu problema. Se ao invés de criarmos todo um novo framework porque não gostamos, especificamente, da forma como ele lida com algum aspecto interno do seu funcionamento, nós contribuissemos com o projeto tornando-o mais adequado? Dessa forma, teríamos menos escolhas, porém, escolhas melhores. Ou, ainda, poderíamos focar criando soluções que nos ajudassem em outros problemas menos batidos por aí.
Se não introduz algo significativo, ao meu ver, não vale a pena ser feito.
[quote=guilherme.chapiewski][quote=saoj]Guilherme, vc está um pouco equivocado e mal-informado.
Quando fizemos o suporte a Auto-wiring e IoC do Mentawai não existia GUICE. Então o GUICE do Google é um Scraptaculous também porque copiou o PicoContainer? Acho que não. Dá uma olhada no Guice que vc vai ver que ele segue a mesma linha do Mentawai.[/quote]
Ok, esqueça o Guice. Sobram todos os outros.[/quote]
Mas o Guice é diferente do Spring e do Pico, ele ja nasceu Java 5 e se aproveitando disso.
]['s
[quote=fabio.patricio][quote=guilherme.chapiewski][quote=saoj]Guilherme, vc está um pouco equivocado e mal-informado.
Quando fizemos o suporte a Auto-wiring e IoC do Mentawai não existia GUICE. Então o GUICE do Google é um Scraptaculous também porque copiou o PicoContainer? Acho que não. Dá uma olhada no Guice que vc vai ver que ele segue a mesma linha do Mentawai.[/quote]
Ok, esqueça o Guice. Sobram todos os outros.[/quote]
Mas o Guice é diferente do Spring e do Pico, ele ja nasceu Java 5 e se aproveitando disso.
]['s[/quote]
Isso mesmo. Aliás, eu não gosto muito do esquema dele de annotations, mas isso não vem ao caso. O fato é que ele realmente introduziu uma novidade e por isso acho que não se encaixa nessa categoria de scraptaculous.
Acho que a diferença foi outra, foi usar configuração programática para configurar os componentes.
Guice:
public class MyModule implements Module {
public void configure(Binder binder) {
binder.bind(Service.class)
.to(ServiceImpl.class)
.in(Scopes.SINGLETON);
}
}Mentawai:
public class ApplicationManager extends org.mentawai.core.ApplicationManager {
public void init(Context app) {
filter(new IoCFilter()); // global filter...
ioc("service", ServiceImpl.class, APPLICATION);
}
}A diferença é que o Mentawai faz o binding por nome de variável ou propriedade (no caso quem tiver uma propriedade “service” vai receber ServiceImpl) e o GUICE faz o binding por annotation (vc coloca @Inject aonde vc quer que receba o ServiceImpl).
O Spring suporta esses dois tipos de bind e não sei se ele suporta annotations. (procure por Spring Annotations do Urubatan)
Mentawai por opção e filosofia não usa annotations, e sim um arquivo de configuração central. O Mentawai não é Scraptaculous porque diferentemente dos outros é um framework focado totalmente em configuração programática central (isso não é annotations, nem xml e se vc acha que o Mentawai não tem conventions clique aqui). E também diferentemente de muitos outros porque é um framework web FULL-STACK, que soluciona todos os problemas repetitivos de uma aplicação web, e não apenas mais um controlador MVC. Diferentemente de muitos outros, possui um stack de entrada (action input) e de saída (action output). Diferementemente de muitos outros, possui suporte nativo a Ajax no server-side e no client-side (MentaAjax). E muitas outras diferenças que só não vê quem não quer ver e apenas criticar.
[quote=guilherme.chapiewski]
Isso mesmo. Aliás, eu não gosto muito do esquema dele de annotations, mas isso não vem ao caso. O fato é que ele realmente introduziu uma novidade e por isso acho que não se encaixa nessa categoria de scraptaculous.[/quote]
Tanto é que algo semelhante foi adicionado ao Spring 2.5. Gostar dele ou nao é um outro detalhe, mas ta fora da discussão.
Ps. Tambem fiquei impressionado como uma discussão que nao tinha nada a ver com o Menta se transformou nisso.
]['s
O Spring já tem suporte a configurações via annotations.
Você não acreditaria se eu te falasse que não é bem assim, acreditaria? Já ouviu falar de Java Server Faces? 
A questão que foi levantada pelo autor do texto que o Guilherme comentou, é que o Mentawai poderia ser um conjunto de facilidades que agrupam vários frameworks, como o JBoss Seam faz com JSF, EJB3 e JPA e o Rails faz com ActiveRecord e os outros, lá.
O Mentawai poderia ser o VRaptor, Nano/PicoContainer e Hibernate. Isso seria uma melhoria no uso dos 3 frameworks, criando uma “arquitetura full-stack” para um tipo de projeto web.
No entanto o que o Mentawai faz é reescrever essas funcionalidades e incluir um facilitar para integrá-las. Esta é a atitude que o autor, do texto que o Guilherme leu, questiona.
É o mesmo que se pergunta qualquer maluco que começa a usar Linux: Por que as pessoas não se juntam e criam uma mega-distro ao invés de dividir o esforço entre um milhão de pequenas distros?
Acho que vc não leu um dos meus posts anteriores quando eu falo que o Mentawai é FULL-STACK e abstrai alguns frameworks dentro dele:
Pool de Conexão: Mentawai, como o Hibernate, abstrai C3P0 e DBCP. E pode abstrair muitos outros através da interface ConnectionHandler.
Envio de Email: Mentawai abstrai o Commons Email dentro dele.
File Upload: Mentawai abstrai o Commons File Upload dentro dele.
Cluster: Mentawai, como o JBoss, abstrai o JGroups dentro dele.
Template para envio de email: Mentawai abstrai um VelocityEngine, e pode abstrair muitos outros através da interface Letter.
Algumas coisas como IoC e Auto-wiring, o Mentawai implementou a sua própria solução. Tenho certeza que o pessoal do Spring e do Pico não está chorando agora porque a gente não abstraiu eles. Foi apenas uma decisão de design. Não pretendemos lançar nenhum framework de IoC e Auto-wiring para concorrer com esses. Principalmente porque o Google já o fez, e muito bem por sinal!
Eu entendi isso. O problema não são as que foram usadas. Mas porque não foi usado nas outras também?
O que eu acho que não consegui explicar é que o autor questiona o porque de as outras funcionalidades(Font-Controller, DI) não são soluções já existentes, com o Mentawai como facilitador. Como o JCompany e o Rails fazem, por exemplo?
A questão é: porque reescrever isso se já existe alguém que faz isso bem? Não seria mais interessante, do ponto de vista da evolução da tecnologia, os novos usarem os existentes, adicionando facilidades?
Acho que a concorrência é saudável. Fiz uma explanação anteriormente fazendo alusão à metáfora que fora colocada em discussão.
Sendo prático e rápido agora: Legal, vc tem uma série de frameworks, que copiam e recriam melhorando funcionalidades. Os saltos nessa evolução vem de sacadas no MEIO deste processo.
O Hibernate se consolidou no mercado e deixou uma série de outros frameworks pra trás, mas há opções e approaches diferentes, como o IBatis.
A questão não é resolver a mesma coisa e sim a abordagem que vc utiliza para resolvê-la. E a bem real, isso é como um garimpo, precisa ter paciência para encontrar e lapidar algo até virar pedra preciosa.
Rails caiu na graça da comunidade, apoiado por uma linguagem fantástica e muitas sacadas geniais, mas tenho certeza que daqui a pouco virá outra, utilizando até Ruby - um framework component based em Ruby sei lá … algo como - Beehive para infra , em ruby dinâmico para integração ( coisas malucas que já pensei em desenvolver ) …
A questão é sentar a bunda e fazer algo decente, isso é para poucos, mas todos querem tentar ter seu lugar ao Sol 
Está errado ? Não acho, veja o que aconteceu com o projeto JBoss, um monte de caras doaram código o mesmo fora vendido e o carinha embolsou sozinho os 300 milhas, assim como Mysql e outras iniciativas.
A historia nao eh bem assim.
[quote=saoj][quote=fabio.patricio]
Mas o Guice é diferente do Spring e do Pico, ele ja nasceu Java 5 e se aproveitando disso.
[/quote]
Acho que a diferença foi outra, foi usar configuração programática para configurar os componentes.[/quote]
Sergio,
Releia o que eu escrevi acima, e me diga em que momento eu comparei o Guice com o Menta?
Porque tu fez toda essa comparacao se eu nem passei perto de citar o Menta?
É tao dificil manter a linha no que esta sendo discutido?
]['s
Alguém aqui sugeriu que seria uma perda de tempo o desenvolvimento de frameworks que não trouxessem nada de novo. Eu concordo, mas acho que é mais perda de tempo ainda discutir se isso é perda de tempo ou não
[quote=fmeyer][quote=Kenobi]
A questão é sentar a bunda e fazer algo decente, isso é para poucos, mas todos querem tentar ter seu lugar ao Sol Está errado ? Não acho, veja o que aconteceu com o projeto JBoss, um monte de caras doaram código o mesmo fora vendido e o carinha embolsou sozinho os 300 milhas, assim como Mysql e outras iniciativas.
[/quote]
A historia nao eh bem assim. [/quote]
Concordo que simplifiquei bastante, mas eu não vi nenhuma doação para a galera que contribuiu …
Concordo com os posts do Maurício…
É TUDO mais do mesmo…
Alguns aqui de vocês estão achando que os desenvolvedores deveriam se unir para a criação de um framework comum, ao invés de ter vários. Mas vocês não acham isso tão utópico quanto a dizer que todos os povos deveriam largar as armas e se darem as mãos?
Olha, até porque, esse negócio de dizer que um bando de gente reunida irá fazer algo decente é mentira! O Projeto por Comitê ( http://en.wikipedia.org/wiki/Design_by_committee ) é um antipadrão conhecido!
Gente, não sei se o excesso de uso de Windows faz uma lavagem cerebral nas pessoas a ponto de achar diversidade uma coisa ruim. Mas gostaria de dizer pra vocês que a diversidade é boa, que a liberdade é boa, e que não dá pra impedir alguém de criar soluções para problemas que outros já solucionaram (mas pode criticar, se quiser). E esse negócio de dizer que o framework Y é igual ao framework X está sempre enviesado pelo olhar pessoal. Poxa! Alguma diferença sempre tem, senão seria dois frameworks com a mesma arquitetura só mudando nomes de variáveis (o que, de fato, não acontece).
Quando falei que seria mais interessante contribuir com um projeto já existente, não me referi apenas às tarefas relacionadas diretamente ao desenvolvimento do mesmo. Uma maneira de contribuir a um projeto sem participar - pelo menos não diretamente - do desenvolvimento, seria contribuindo com documentação, ajudando pessoas que utilizam o software, ajudando a melhorar a qualidade enviando patches e/ou notificando sobre defeitos do software, usando nos seus projetos contribuindo na identificação de funcionalidades que faríam da sua vida e de outros desenvolvedores mais fácil.
O problema é que quando as opções são muito maiores do que sua capacidade de se informar sobre as diferenças de cada uma das alternativas o que acontece é que se torna impossível tomar uma decisão baseada na razão e acabam optando por aquilo que já conhece (ex: struts).
Por exemplo a comunidade linux, muita gente faz muito pela comunidade linux, mas nem todo mundo é commiter e/ou líder de um projeto de uma distribuição.
Claro que alguma coisa sempre muda, mas alguém em sã consciencia indicaria a uma pessoa mudar a ferramenta que sua equipe está acostumada a desenvolver porque uma delas faz a funcionalidade X com o framework da moda enquanto o outro framework faz a funcionalidade Y com outra biblioteca menos “atual”?
O que o autor disse é que tem que ser algo mais significativo e nada menos coerente do que isso.
A minha posição (e a do autor) é simples: se não for fazer melhor (ie: algo que traga RESULTADOS claramente superiores às soluções já existentes e que REALMENTE valha a pena migrar) contribua de outra forma.
Ah, sei, um bando de gente reunida nunca dá algo decente né?
Deve ser por isso que o Spring é um fiasco, tem gente demais mexendo ali. Tenha dó companheiro, tenha dó.
E é claro que alguma diferença sempre tem, eles mudam os nomes dos pacotes, oras. Você refaz uma coisa igual ou muito parecida quando o original tem problemas graves (que é o caso de RoR, o Merb não surgiu do nada, surgiu pra tentar resolver o problema de um request por vez do rails), mas eu nunca vi nenhuma falha absurda ou inutilizável em outros frameworks como o WebWork, Spring MVC e congêneres, fizeram outros porque queriam fazer outros, não foi porque ninguém teve uma idéia revolucionária não.
E não me venham comparar RoR com frameworks Java não, não adianta comparar jaca com abacaxi. O máximo que os “novos” frameworks web em Java trazem de novo é o tal do “convention over configuration”, que sempre pôde ser feito em qualquer um dos outros frameworks (todos eram e continuam sendo configuráveis programaticamente), só que ninguém tinha ainda parado pra pensar nisso antes do DHH fazer.