Lançado Mentawai 2.5.1 ainda mais simples com site novo e documentação toda refeita e revisada!

Assuntos Gerais Notícias
#1

Depois de um bom esforço estamos lançando o novo site do Mentawai. A documentação foi reescrita do ZERO e revisada. Nunca foi tão fácil fazer aplicacões web com Java de uma maneira simples, direta e clara. Acesse o site e leia a descrição abaixo:

http://www.mentaframework.org

O Mentawai é um framework web full-stack, action-based, MVC e open-source em Java criado em Junho de 2005. Desde então ele tem sido fiel à sua filosofia que é oferecer uma solução simples de alto nível para o desenvolvimento de aplicações web sem XML e Annotations, usando uma configuração programática centralizada para preparar e ligar todas as partes de uma aplicação web. Ele suporta inteiramente o princípio KISS utilizando altos níveis de abstração para exterminar qualquer complexidade. Se você não for capaz de entender ou utilizar qualquer funcionalidade do framework a culpa é do framework e não sua.

Uma das principais características do Mentawai é a sua abordagem full-stack, ou seja, você não precisa utilizar nenhum outro framework para implementar as funcionalidades recorrentes de toda aplicação web. Tudo é abstraído e fornecido pelo framework de uma maneira simples de entender e fácil de utilizar. Essa é a mesma abordagem utilizada por outros frameworks como o Ruby on Rails, Play e Riffe.

Por incentivar uma configuração programática via código Java, o Mentawai elimina a famosa programação em XML ou a Annotations Programming (também conhecida como Annotationmania) bastante comum na maioria dos frameworks Java. O Mentawai foi o primeiro framework web em Java a seguir esse caminho ainda em 2005.

Resumindo, o Mentawai oferece:

:arrow: Uma solução full-stack (completa) pra desenvolvimento web, desde IoC (Inversão de Controle), passando por autenticação, acesso a banco de dados, envio de email, validação, tags da camada de visão, Ajax, etc.
:arrow: Dedicação completa ao princípio KISS. Se não for simples e fácil então há um erro no sistema.
:arrow: Uma abordagem programática para a configuração, o que não significa que não haja convenções e padrões para tudo.
:arrow: Alta produtividade com prazer no desenvolvimento de aplicações web, para que você possa focar no seu projeto sem que o framework te atrapalhe.

Caso queira experimentar você pode dar uma olhada no quick start: http://www.mentaframework.org/mtw/Page/QuickStart/mentawai-quick-start

Caso queira ver a aplicacão de referência: http://www.mentaframework.org/mtw/Page/RefApp/mentawai-aplicacao-de-referencia

Qualquer dúvida, crítica ou comentário estamos a disposicão.

#2

saoj anda inspirado ultimamente… parabéns pelos projetos.

#3

Quando a motivacão aparece é bom aproveitar antes que ela vá embora. :slight_smile:

Recomendo dar uma olhada no suporte de IoC do framework. Na minha opinião um dos melhores que existem: http://www.mentaframework.org/mtw/Page/IoC/mentawai-inversao-de-controle

#4

Você é meio suspeito de falar né?! :lol: :lol: :lol:

Parabéns aí pela iniciativa. [=

#5

Você é meio suspeito de falar né?! :lol: :lol: :lol:

Parabéns aí pela iniciativa. [=[/quote]

Totalmente suspeito!!! Mas se achar um framework web que ofereca um suporte a IoC, DI e Auto-Wiring mais completo simples e transparente que o Mentawai me avise. Pode existir mas eu nunca vi…

@Override
public void setupIoC() {
 
    ioc("userDAO", JdbcUserDAO.class); // para a minha interface UserDAO eu quero utilizar a implementação JdbcUserDAO
    // (...)
}

public class UserAction extends BaseAction {
     
    private final UserDAO userDAO;
     
    public UserAction(UserDAO userDAO) {   // <==== Constructor DI: Vai receber um JdbcUserDAO aqui
        this.userDAO = userDAO;
    }
 
    // (...)
}

É simples assim. E o framework faz todo o wiring de forma automática.

#6

Você poderia dar uma breve descrição do que é Configuração Programática?

Para nós mortais que não temos acesso a quase nada além do GUJ, rs.

#7

Eu vou aceitar o desafio.
Preciso desenvolver um aplicativo de controle de estoque, para um ramo de atividade de intensa movimentação, com alto consumo de banco de dados, devido às idas e vindas dos produtos.
Pois bem, hoje mesmo irei baixar as libs do menta e irei desenvolver o projeto.
Vamos ver se daqui a 3 meses ele está concluído e rodando perfeitamente, sem qualquer outro framework.
Caso esteja, eu volto aqui e dou o relato e toda a informação a respeito de como foi desenvolver o projeto com o mentawai.

#8

[quote=digaoneves]Você poderia dar uma breve descrição do que é Configuração Programática?

Para nós mortais que não temos acesso a quase nada além do GUJ, rs.[/quote]

Sendo bem objetivo, sem enrolar:

Num framework FULL-STACK há diversas coisas que precisam ser setadas ou configuradas. Por exemplo, IoC é bem óbvio. No Mentawai você faz isso na classe AppManager que é a tal da configuracão programática, ou seja, é PROGRAMA ou código Java ao invés de XML ou Annotation.

public class AppManager extends ApplicationManager {

    // (...)

    @Override
    public void setupIoC() {
    
        ioc("userDAO", JdbcUserDAO.class); // para a minha interface UserDAO eu quero utilizar a implementação JdbcUserDAO

       // (...)
    }
}

Em outros frameworks você faria isso via XML central ou Annotations espalhadas pelo seu código. No Mentawai a configuracão é CENTRAL e PROGRAMÁTICA. Vantagens disso:

  • Mais prazerosa e natural.
  • Menos propensa a erros pois a IDE compila e checa pra vc.
  • Auto-complete, auto-compile e refactoring e todas as sacadas do Eclipse pra Java.
  • Flexibilidade. Como vc configura 100 actions diferentes num XML ou via annotations? Com o Mentawai vc faz um for loop ou o que quiser. A configuracao está no seu comando e não o oposto.

Isso em 2005 foi uma pequena revolucão. Todos foram contra, claro. Só que hoje em dia quase todos os frameworks comecam a se render a configuracao programatica. Spring, Hibernate, etc.

Etnretanto essa não é o grande diferencial do Mentawai. É parte do diferencial mas o grande barato do framework é a:

  • PRODUTIVIDADE
  • SIMPLICIDADE
  • FACILIDADE
  • FULL-STACK
  • STAY OUT OF THE WAY APPROACH

Querendo ver a configuracao programática na prática, veja aqui: http://websvn.soliveirajr.com/filedetails.php?repname=MentaTutorials&path=%2FMentaRefApp%2Ftrunk%2Fsrc%2Fmain%2Fjava%2Forg%2Fmenta%2FAppManager.java

Veja como as actions, os filtros, o envio de email, o IoC, etc são configurados.

#9

[quote=drsmachado]Eu vou aceitar o desafio.
Preciso desenvolver um aplicativo de controle de estoque, para um ramo de atividade de intensa movimentação, com alto consumo de banco de dados, devido às idas e vindas dos produtos.
Pois bem, hoje mesmo irei baixar as libs do menta e irei desenvolver o projeto.
Vamos ver se daqui a 3 meses ele está concluído e rodando perfeitamente, sem qualquer outro framework.
Caso esteja, eu volto aqui e dou o relato e toda a informação a respeito de como foi desenvolver o projeto com o mentawai.[/quote]

Não vai precisar de FRAMEWORK nenhum. Nem Spring, nem Hibernate, nem nada. Eu gosto de SQL mas entendo que muitos gostam do Hiberante, logo o Mentawai oferece um ótimo suporte ao Hibernate caso e apenas caso vc queira usá-lo.

Esse é o grande barato dos frameworks FULL-STACK como Ruby on Rails, Play e Mentawai. Tudo, tudo mesmo, foi abstraído. Vc não precisa trazer Spring, Hibernate, Log4J, commons email, file upload, JSTL, JAAS, blah, blah, blah. Com essa salada de frameworks, exterminar a complexidade e ABSTRAIR vira uma tarefa impossível.

Há vários sistemas em producao usando o Mentawai com milhares de acessos simultâneos.

#10

Oi Sérgio,

Já usei Struts 1.x, JSF 1.x e tentei usar o VRaptor 3 algumas vezes, mas a quantidade de problemas que deu com as dependências me tiraram do sério… É mudar a versão de um jar que pronto, o negócio para de funcionar…
Enfim, eu simplesmente não acredito em frameworks Web em Java, pois nunca tive uma experiência plenamente boa e produtiva. Na primeira vez q vc precisa fugir um pouquinho do que qq framework que já usei faz, pronto, é aquela loucura. Ou seja, uso Servlets, JSPs, JSTL e algumas custom tags que criei… Desencanei dos frameworks há um bom tempo (vide as versões que usei). Podem me chamar de arcaico, contra produtivo, etc., mas ainda não consegui achar algo que realmente me atenda. Minha última empreitada foi testar JSF 2 com o Primefaces. Até que gostei, mas sinceramente, não sei se adotaria.

Vou experimentar o Menta para ver se mudo minha concepção sobre isso :wink:

[]'s

#11

(Alarme falso)

#12

http://www.mentaframework.org

Sérgio, corre lá que o site tá fora do ar!

#13

[quote=Rodrigo Vieira Pinto]http://www.mentaframework.org

Sérgio, corre lá que o site tá fora do ar![/quote]

Pra mim funciona no firefox mas no chrome não aparece nada… Que ótimo !!! :slight_smile:

Acho que agora está ok !!! Dá uma olhada aí… Era pau no meu Chrome !!!

#14

@saoj, muito legal o fw, de cara impressiona pela quantidade de recursos, é muito trabalho, e pelo que vi muito bem feito.

Parabéns.

Só um detalhe, no IoC, não seria mais legal usar Classe da interface e não a String?

[code]@Override
public void setupIoC() {

ioc("userDAO", JdbcUserDAO.class); // for my UserDAO interface, I want to use the JdbcUserDAO implementation

}[/code]

[code]@Override
public void setupIoC() {

ioc(UserDAO.class, JdbcUserDAO.class); // for my UserDAO interface, I want to use the JdbcUserDAO implementation

}[/code]

#15

Usei num projeto comercial o Menta 1.13+displaytags+Jasperreports+MySQL5.0(jdbc).

Eu era muito cru em WEB, pois sempre fui desenvolvedor Swing(a qual continuo até hoje), e os conceirtos são fáceis.
Era uma aplicação que não era gigante(algumas centenas de usuários), mas em dados períodos do mês essas centenas acessavam os dados no mesmo dia gerando relatórios feito loucos.O footprint da App era baixíssimo, até o dono do server falou que o uso de memória geral era baixo da minha app.O único cuidado especial que tive foi de fazer um cache para os dados mais acessados dos relatórios, tirando isso, era puro CRUD de dados.

Se a qualidade é a mesma, recomendo o Menta para qualquer um que for desenvolver para WEB, e se tivesse um projeto novo na área provavelmente o faria. :wink:

#16

[quote=daveiga]@saoj, muito legal o fw, de cara impressiona pela quantidade de recursos, é muito trabalho, e pelo que vi muito bem feito.

Parabéns.

Só um detalhe, no IoC, não seria mais legal usar Classe da interface e não a String?

[code]@Override
public void setupIoC() {

ioc("userDAO", JdbcUserDAO.class); // for my UserDAO interface, I want to use the JdbcUserDAO implementation

}[/code]

[code]@Override
public void setupIoC() {

ioc(UserDAO.class, JdbcUserDAO.class); // for my UserDAO interface, I want to use the JdbcUserDAO implementation

}[/code]

[/quote]

Por isso que eu gosto e falar que é o melhor que existe, para alguém se sentir desafiado, pensar e colocar uma sugestão de alto nível como essa sua. :slight_smile:

Mas acho que não, pelo seguinte:

Quando vc faz injection via construtor, o nome é IRRELEVANTE como vc muito bem notou. Mas quando vc faz INJECTION vai setter o nome é o nome da propriedade. Mas poderia também tentar adivinhar o setter pelo seu parâmetro, como é feito com o construtor. :roll:

Entretanto o que vc falou é muito certo e facilita refatoracao. String são sempre propensas ao erro. No caso de injection por construtor o nome do componente é irrelevante, pois em Java os parametros de um construtor ou método não possuem “nomes” que podem ser acessados por reflection.

Poderia haver o caso de vc ter a mesma interface e dois componentes diferentes para a mesma interface !? Daí isso que vc falou não funcionarei, certo? Mas estou pensando aqui e acho que esse caso deve ser bem raro.

Vou pensar nisso que vc falou. Realmente faz um certo sentido. Eu falei que o IoC era bom e não perfeito. Tudo pode ser sempre melhorado ad eterno. Valeu pela dica!

UPDATE1: O Spring se eu não me engando marca componentes por NOME e não por interface. A única coisa que me vem a mente aqui é que para descobri o setter apenas pelo tipo do parametro vai dar um trabalho e pode gerar ambiguidade. Por nome vc vai direto na propriedade. Mas não sei se isso é uma boa desculpa não… Vou avaliar essa mudanca no MentaContainer.

UPDATE2: Nem que eu tenha que fazer um smiples UserDAO.class.getSimpleName() por trás dos panos já seria muito melhor.

Bom, acho que depois dessa sua dica a coisa vai ficar no ponto, mas dessa vez não vou falar nada. :slight_smile:

#17

Amigo… eu tenho a mesma opnião que a sua… Hoje no atual sistema estou usando Servlet e também fiz um sistema próprio que estou usando Servlet (na verdade implementei um Front Controller), pois geralmente se precisa de coisas que o framework não faz…
Testei o Prime Faces e gostei bastante, mas minha opnião sobre JSF é que só serve para aplicativos web e não para sites e mesmo assim deixa a desejar em alguns pontos, pois minha opnião é que quando se utiliza o Browser, o sistema fica melhor se tiver cara de site e não o contrário… acho que tentativa de fazer sistema com cara de desktop no browser é meio furada… já tive tanto problema com isso que hoje prefiro muito mais usar swing ou swt, pois ainda acho que o overhead de se fazer muito ajax causa problemas de performance e sincronismo dificeis de solucionar (as vezes dependendo do framework quase impossiveis).
Hoje estou utilizando Servlet, JSP, JSTL e DWR. Custom Tags também, mas por incrivel que pareça cheguei a conclusão que as vezes um pequeno scriptlet não faz mal (mas são raros os casos)… dar tanta volta para evitar um scriptlet de 3 linhas as vezes não vale a pena!

Sérgio,

Participo a pouco tempo do GUJ (embora o leia a muito… muito tempo)… e tenho um pensamento parecido com o seu em relação a como deve ser o desenvolvimento Web… eu gostei do Menta mas nunca o utilizei em um projeto… pois a maior parte dos sistemas que defini a arquitetura do zero precisavam compartilhar componentes entre desktop e web e preferi fazer tudo na unha com POJOs para não perder flexibilidade… talvez o Menta atendesse bem…

Vou testar a nova versão e quem sabe não migre alguns sistemas próprios para ela.

#18

Para aplicacoes distribuídas ou que precisem de integracao com EJB, WebServices, Desktop, etc. é legal adicionar uma segunda camada na sua aplicacao de SERVICE. Logo ao invés de:

Action -> DAO -> VIEW

Action -> SERVICE -> DAO -> VIEW

A aplicacao de referencia também foi implementada com essa arquitetura aqui: http://websvn.soliveirajr.com/listing.php?repname=MentaTutorials&path=%2FMentaRefAppWithService%2Ftrunk%2Fsrc%2Fmain%2Fjava%2Forg%2Fmenta%2F&#a481b86b6eecd19ba856562af62299f20

(Gracas ao Robert que implementou uma aplicacao sinsitra de reserva de passagens aéreas com o Mentawai)

#19

@saoj minha sugestão foi pensando justamente na Refatoração via IDE, Strings são sempre complicadas…

Aproveitando que você falou da injeção via setter, como funcionaria sem anotações? O Container carre todos os setters procurando quais deles esperam um tipo injetável?

O Spring realmente usa nomes pra identificar os beans, e usa a mesma padronização que você quando você omite o identificador declarando o bean via anotação. Mas nos settrs você diz em “quais” setters você quer injetar.

Uma ideia que contemple o cenário em que há 2 beans implementando a mesma interface seja uma sobescrita com terceiro parâmetro:,

[code]@Override
public void setupIoC() {

ioc(UserDAO.class, JdbcUserDAO.class); // cria o bean userDAO
ioc(UserDAO.class, JPAUserDAO.class, "jpaUserDao"); // cria o bean jpaUserDAO

}[/code]

UPDATE: Aumenta a verbosidade, que você quer evitar, mas só no caso incomum, no caso comum continua como antes.

#20

Sim, se vc tira o “nome” do IoC e deixa apenas o TIPO então tem que fazer isso mesmo. Teria ver se tem como colocar algum cache para fazer isso APENAS uma vez e cachear o setter encontrado. Se bem que o hit de performance aí deve ser irrelevante, acredito eu.

Por nome vc vai direto ao ponto, ou seja pega o método setNome.

É para pensar mas via interface é muito melhor para a refatoracao e evitar typos, o ponto forte da configuracao programática.

Esse caso de vc usar duas implementacoes diferentes na mesma aplicacao ao mesmo tempo me parece bem raro. É meio contraditório. Vc vai querer usar uma coisa ou outra.