Só faltou um exemplo no site lá… Um HelloWorld…

Se vc conseguir algum exemplo aí posta aqui para a gente ver…

Exemplos estão aqui: http://docs.google.com/Doc?id=dd2fhx4z_5df5hw8

Classe de módulo que configura o, humm… , o módulo.

public class MyModule extends AbstractModule {
  protected void configure() {
    bind(Service.class)
      .to(ServiceImpl.class)
      .in(Scopes.SINGLETON);
  }
}

E a classe que utilizará o serviço:

public class Client {

  private final Service service;

  @Inject
  public Client(Service service) {
    this.service = service;
  }

  public void go() {
    service.go();
  }
}

Apenas para termos algo com o que compará-lo, abaixo segue um exemplo idêntico com o Mentawai:

(Se alguém quiser colocar um exemplo usando Spring, Struts, etc. seria bom tb)

public class MyAppManager extends ApplicationManager {
  
   public void init(Context application) {

      ioc("myService", ServiceImpl.class, APPLICATION);

   }
  
   public void loadActions() {
    
      filter(new IoCFilter());
      filter(new InjectionFilter());

   }

 }

public class MyAction extends BaseAction {

    private Service myService;

    public String execute() throws Exception {

        myService.go();

        return SUCCESS;

    }
}

Uma diferença que eu vi é que eles estão fazendo injection via construtor. Com o Mentawai vc pode fazer injection via setter ou diretamente no campo privado como o exemplo acima, ou seja, sem qualquer setter.

Eles suportam injection diretamente em campo privado também? (Devem suportar…)

Olá,

Ontem eu estava conversando com o Plentz sobre o framework. Sinceramente achei legal, mas nao gostei desse AbstractModule. Tem um cheiro ruim esse negocio.

]['s

Sérgio, calma :D

o Guice não é um concorrente do mentawai ...
ele é só um container para DI ...
e como container para DI ele é muito mais flexivel que o mentawai, ele suporta injeção via setter e constructor.

tem um suporte muuuiittoooo fraco a AOP, e não tem absolutamente nada a ver com MVC nem web, é só infra mesmo ...

@ImplementedBy(ServiceImpl.class)
public interface Service {
  void go();
}

@Singleton
public class ServiceImpl implements Service {
  public void go() {
    ...
  }
}

public class Client {

  private final Service service;

  @Inject
  public Client(Service service) {
    this.service = service;
  }

  public void go() {
    service.go();
  }
}

bind(Service.class)
  .annotatedWith(Blue.class)
  .to(BlueService.class);

@Inject
void injectService(@Blue Service service) {
  ...
}

class Mixer {

  @Inject
  Mixer(Concrete concrete) {
    ...
  }
}

isto foi o que ja deu tempo de eu ver do Guice ...
tem algumas coisinhas que não achei legais nele também, mas isto fica pra outra hora ...

fabgp2001:

Olá,

Ontem eu estava conversando com o Plentz sobre o framework. Sinceramente achei legal, mas nao gostei desse AbstractModule. Tem um cheiro ruim esse negocio.

]['s

é que tem um cheiro estranho.
</modo espero que ninguem saiba do que to falando>

To calmo. Como falei apenas dei um exemplo para “ter com o que comparar”.

Claro que não é concorrente. O Guice é genérico para ser usado com qualquer tipo de aplicaçao (web, distribuída, etc). Já o IOC/DI do Mentawai é do Menta para o Menta.

Vc quer dizer mais genérico e não mais flexível. O Mentawai suporta injeçao por construtor, setter e tb direto no campo privado. Parece que é tão flexível quanto o Guice. Só não é mais genérico pois como eu falei é do menta para o menta.

O fato do mentawai oferecer um bom suporte a IOC e DI faz com que as coisas fiquem muito mais simples. O que é mais fácil: usar um framework para web e DI ou dois frameworks: um para web e outro para DI?

A resposta é subjetiva, mas acredito que usando um framework só que já te oferece todas as principais soluções vai facilitar a vida. Nada te impede de usar tb 10 frameworks num projeto, se vc domina bem esses 10 frameworks.

urubatan:

<modo espero que ninguém saiba do que to falando>
abstract module não tem cheiro ruim, classes com todos os métodos static, implementando regra de negócio com dados apenas em memória sem suporte a transações, em que a unica forma de se criar um vo é inserindo dados no “banco em memória sem suporte a transações”, e com todas as classes que não são puramente estáticas tem construtores package private tornando quase impossível se criar um mock para escrever os testcases.

é que tem um cheiro estranho.
</modo espero que ninguem saiba do que to falando>

Quem dera se fosse só isso que tivesse cheiro ruim.

Mas voltando não é tao feio, so nao gosto da ideia de ter que criar um módulo pra fazer essa configuração. Ta certo que nao é obrigatorio.

]['s

Ai eu concordo com o Urubatan. Comparar pessego com manga nao é algo bom.

O ideia seria uma comparacao com Pico e Spring.

]['s

Certa resposta!

Spring best java framework ftw

Acho que a comparaçao foi pertinente. Ambos fazem a mesma coisa, só que o Guice é um framework genérico para DI e o Mentawai um framework web que suporta também DI.

Os códigos ficaram até bem parecidos…

Alguém ai poderia colocar comparativos com Pico e String também.

Mas hein?

Leozin:

Hal Jordan:

• “Spring é melhor!!!”
  

Certa resposta!

Spring best java framework ftw

Eu sabia, Eu sabia, Eu sabia… hahaha… Que ia ter um comentário sobre o Spring…

A questão não é o Spring, e sim o Guice… qq ele pode trazer pros seus projetos???.. Se eu precisar somente IoC/DI o Guice se mostrou um framework compentente, simples. Bem mais simples q o Spring…

Mas agora se eu preciso de controle de transações, segurança, etc… (q não é o foco do Guice) eu prefiro o Sp… EJB3.

Enfim, a questao nao é comparar o full set do Spring, mas sim o DI, q pelo jeito o Guice tá se monstrando bem simples…

Spring tá aqui : http://code.google.com/p/google-guice/wiki/SpringComparison

Mas a comparação com o String é meio dificil, deixo isso como tarefa pra evangelistas!!!

O P e o T ficam muito proximos.

Hal Jordan:

saoj:

Alguém ai poderia colocar comparativos com Pico e String também.

Spring tá aqui : http://code.google.com/p/google-guice/wiki/SpringComparison

Mas a comparação com o String é meio dificil, deixo isso como tarefa pra evangelistas!!!

Acho que eles foram bastante políticos na comparação com Spring. O que pareceu é que eles estão falando entrelinhas que “O Guice é mais simples que o Spring”.

Mencionam tb o fato do Spring ter muito XML. Não acredito que nessa altura do campeonato o Spring ainda não tenha uma configuração programática como o Guice e como o Mentawai. Alguns vão dizer que preferem XML. Ok! Gosto não se discute, mas foi bom ver que os caras do Google também gostam de configuração programática.

Outra observação interessante é que eles defendem o uso de annotations. Eu ainda estou me definindo sobre isso, mas acredito que annotation é intrusivo. Se vc tem um modelo de dados que recebe um DAO, vc pode colocar uma annotation no campo do DAO para dizer que ele vai receber a implementação vai IOC. Mas vc não estaria atrelando o seu modelo a annotation do container de IOC ???

O que o Mentawai faz é usar o nome da propriedade para definir a dependencia, ou seja, quando eu defini o IOC eu associei um nome a ele, no caso “myService”:

ioc("myService", ServiceImpl.class, APPLICATION);

Logo não precisa de annotation pois o InjectionFilter vai ver que o nome da propriedade da action é “myService” e vai procurar por uma implementação de Service com o nome “myService”.

A única desvantagem pequena disso é que se vc tem duas classes com duas propriedades com nomes diferentes, vc vai precisar definir o IOC duas vezes:

ioc("myService", ServiceImpl.class, APPLICATION);
ioc("myServiceAgain", ServiceImpl.class, APPLICATION);

Usando as boas práticas de organização, o seu serviço pode e deve ter o mesmo nome em todos os lugares que ele aparece na sua aplicação. Caso contrário, ter que definir duas vezes como foi feito acima tb não me parece nada demais…

Sérgio, a parte ruim de definir IoC da forma como o Mentawai e o Spring fazem, que é usando uma tonelada de strings para definir os injection points, é que acopla demais a lógica de wiring com detalhes do modelo. Se trocar o nome do atributo, tanto Spring e Mentaway vão fazer a coisa errada, usando annotations você evita isso.

Também concordo com você que é um problema usar annotations no modelo, pois ele passa a depender do framework. Tudo é uma questão de tradeoff. Qual você está pronto para aceitar.

Pessoalmente acho que Annotations são menos problemáticas, já que as classes injetadas possuem uma dependencia implicita no container de DI, pois não funcionam sem alguém exercendo esse papel. Então, com annotations diminui a quantidade de configuração e conhecimento que teu container tem sobre as classes injetadas, o que me parece sadio.

No caso do Spring tem a opcao de escolher o tipo de wiring que será usado. Esse problema so ocorre quando wiring “byName” é usado o que não é aconcelhado pelo pessoal do Spring. Claro se nao usar ele a quantidade de configuracao cresce muito.

]['s

Eu diria que vc raramente vai trocar o nome do atributo, mas concordo que é um trade off, da mesma maneira que é um trade off atrelar o modelo ao framework usando annotation.

Como vc falou é uma questão de escolher qual trade off vc prefere.

Eu pessoalmente acho que nome de variável raramente muda:

private Connection connection;

private BookDAO bookDAO;

Mas se por exemplo se vc fizer um typo no nome da variável, ou seja:

ioc("bookDAO", MySQLBookDAO);

private BookDAO bookDao;

Não vai funcionar e vc vai ter que debugar isso… Mas typo é typo né?

fabgp2001:

No caso do Spring tem a opcao de escolher o tipo de wiring que será usado. Esse problema so ocorre quando wiring “byName” é usado o que não é aconcelhado pelo pessoal do Spring. Claro se nao usar ele a quantidade de configuracao cresce muito.
]['s

Cara, na real todo mundo usa wiring “byName” e dificilmente auto-wire, eu nunca vi um projeto Spring que não fosse todo com wiring-by-name.

Minha maior birra com Spring era o tamanho monstruoso do xml, mas agora com o 2.0 isso mudou muito.

louds:

fabgp2001:

No caso do Spring tem a opcao de escolher o tipo de wiring que será usado. Esse problema so ocorre quando wiring “byName” é usado o que não é aconcelhado pelo pessoal do Spring. Claro se nao usar ele a quantidade de configuracao cresce muito.
]['s

Cara, na real todo mundo usa wiring “byName” e dificilmente auto-wire, eu nunca vi um projeto Spring que não fosse todo com wiring-by-name.

Pois é, eu ja vi e é um saco de trabalhar. O ponto que eu quiz tocar nem foi se usam ou nao, mas sim que há a opcao. Claro que a facilidade do “byName” nao tem comparacao.

]['s

Acho que a parte boa de utilizar Spring, é que você pode tirar proveito de outros módulos, como mvc, aop, hibernate entre outros.

Aí você começa a sentir que o projeto tem um ganho legal, apesar dos XMLs de configuração.

Estou começando a estudar o SEAM e como a integração com o Spring poderia beneficiar meu projeto.

Poxa cara eu não vejo isso como algo ruim, pelo contrário, acredito que XML veio muito mais pra facilitar do que pra “piorar a vida” do desenvolvedor. Eu prefiro mil vezes fazer gerenciamento/configurações de transações e aop pelo Spring (declarativo) do que ter que fazer na mão ou annotations todos os códigos. Sim, há lugares que as anotações caem muito bem (vide hibernate3/ejb3) até mesmo as transações declarativas @Transaction, mas pra mim XML é muito necessário em várias casos

E que tal configurar o Spring programaticamente?

http://blog.interface21.com/main/2006/11/28/a-java-configuration-option-for-spring/

Leozin:

Poxa cara eu não vejo isso como algo ruim, pelo contrário, acredito que XML veio muito mais pra facilitar do que pra “piorar a vida” do desenvolvedor.

Kra, sei lah, XML normalmente dá mais problema do que solução.

Quando c escreve algo errado no XML, normalmente vai dar um erro em Runtime que não tem nada a ver com o problema.

Eu ainda axo q a cada dia mais e mais projetos estão fugindo do XML.

Pode ser viagem minha, mas eu fujo do XML o tanto quanto possível!

VELO

class MeuXyz extends AbsctractXyz??!?

É sério que as pessoas ainda constroem frameworks onde os módulos não são POJOs?

pcalcado:

class MeuXyz extends AbsctractXyz??!?

É sério que as pessoas ainda constroem frameworks onde os módulos não são POJOs?

Mas ai daonde viriam os metodos para configurar as coisas?

Soh se fosse assim:

public MyModule {

     public void configure(Configurator conf) {

         conf.bind("blah.class'').to("blahImp.class'').etc(...);

    }
}

A unica vantagem seria que o modulo nao extenderia ninguem, mas do mesmo jeito ele ficaria dependente do framework…

Vale a pena isso?

Opções…

1 - Como o Spring faz
2 - Convention over configuration no nome dos métodos, exceção tratada com uma anotação, acho que é o que o VRaptor faz

Nao tenho ideia…

Para o metodo configure() sem problemas. Mas dentro desse metodo vc vai ter que chamar outros metodos para configurar a coisa, e esses metodos tem que vir de algum lugar. CoC nao resolve aqui…

Acho que soh tem duas opcoes:

1 - Estende uma classe abstrata.

2 - Passa um Configurator como parametro de configure().

De um jeito ou de outro tem uma dependencia…

É impossivel você reusar algo q alguem fez sem criar algum tipo de depencia…

Antes uma fisica (implementar ou extender algo) do q uma metafisica (ah, o metodo tem q ser void, tem q receber como parametro xyz, tem q ter um atributo privado na classe chamado JJJ, etc)

E eu prefiro uma dependencia compilável do que uma não compilável! (Jogar dentro de um XML já era compilação, reflexão tbm)

VELO

Sérgio, não entendi a parte em negrito. Pode dar um exemplo com código?

Não acho que o Guice e o Spring sejam tão concorrentes assim. Afinal o Spring é uma stack para a criação de aplicações enquanto o Guice é apenas um framework para DI. Entendi alguma parte errado?

valeuz…

Sérgio, não entendi a parte em negrito. Pode dar um exemplo com código?

public MyModule {
 
      public void configure() {
 
          // como eu configuro aqui dentro alguma coisa ???

         // nao tenho nenhum metodo para chamar, ou seja, nao posso fazer  nada...

     }
 }

Opcoes:

1. Heranca

public MyModule extends AbstractModule {
 
      public void configure() {
 
           bind("asdfasdf").to("asdfsdaf");
     }
 }

2. Parametro

public MyModule  {
 
      public void configure(Configurator conf) {
 
           conf.bind("asdfasdf").to("asdfsdaf");
     }
 }

3. Classe estatica (ruim demais)

public MyModule  {
 
      public void configure() {
 
           Configurator.bind("asdfasdf").to("asdfsdaf");
     }
 }

Eu prefiro disparado a opcao 1).

Acho que criou-se um preconceito contra heranca injustificavel.

Dentro do seu modelo de negocios e entidades ela deve ser usada com parcimonia, talvez ate ser evitada em prol de composicao.

Mas quando temos actions, modulos, e essas outras coisas do framework para o framework, nao ha porque nao usar heranca.

Há sim: testabilidade e desvínculo do framework e da infra-estrutura, acoplamento, coesão e cogeneridade. Além disso herança dificilmente faz sentido fora de uso polimórfico num ponto de vista meramente técnico.

Mas voltando ao caso específico, eu não entendi seu exemplo. Vamos supor que eu tenha um módulo A que dependa de um módulo B.

Eu posso simplesmente utilizar metadados:

pseudocodigo:

@id("moduloA")
class A {

 //CoC, eu sei que existe um modulo A logo posso padronizar o injetor
 public void injectModuloA(){}

 //ah, mas eu posso querer utilizar um outro nome, entao eu saio do padrao e uso uma anotação. meu container pode inferir o tipo da dependencia ou o ModuloA em camelcase

 @injectmethod
 public void setModuloA(){}
 

 //Ok, mas eu quero usar um nome muito alienígena, código legado, por exemplo

 @injectMethod("moduloA")
 public void ipsunLorem(){}

}

Bem parecido com EJB 3.0.

É exatamente assim que o spring funciona, com configuração em metadados (se são XML ou pqp é outro papo). Fazer o módulo depender do framework é uma das principais falhas do Struts, por exemplo.

Note que se você precisa dar o bind de um componente num objeto qualquer você não está usando IoC, está usando Registry. Quem faz isso é o container.

Ou seja, ao invez de atrelar com uma classe atrela com um monte de annotations?

VELO

pcalcado:

Há sim: testabilidade e desvínculo do framework e da infra-estrutura, acoplamento, coesão e cogeneridade.

Com esse codigo cheio de anotacoes isso que vc falou ai em cima ficou contraditorio. Ou nao?

Usar uma coisa sem se atrelar a ela, me parece overkill, ou seja, perde-se muito e ganha-se pouco.

O seu modelo de negocios junto com as suas entidades, esses sim, nao devem estar atrelados a nada.

pcalcado:

class MeuXyz extends AbsctractXyz??!?

É sério que as pessoas ainda constroem frameworks onde os módulos não são POJOs?

Achei que era so eu que nao tinha gostado daquela parada.

]['s

Soh falta agora apresentar motivos ne?

Vc prefere se atrelar a uma classe herdando ela e ganhando de presente um monte de funcionalidades ou usar anotacoes atrelando do mesmo jeito?

Mais uma vez repito: estamos falando aqui de actions, modulos, registars e por ai vai. Nao estamos falando de modelo de negocio e suas entidades, que eh claro pra todo mundo que nao deve se atrelar a nada. Vejam novamente a classe MyModule e reparem que ela eh uma coisa do framework para ser usado com o framework e nada mais. Assim como um arquivo XML e as anotacoes o sao…

Acho que temos um anti-pattern aqui. Pegaram a heranca como bode-espiatorio…

Sim e não.

Meu código não depende de absolutamente nada do framework, o que o deixa compeltamente desacoplado.

Um possível problema seria metadados. Metadados não deveriam ser considerados como vínculo entre um framework e um objeto, mas eu acredito que anotações estaticamente etipadas como as de Java são um problema.

Ainda não consegui dimensionar isso em um modelo real, então não tenho conclusões, mas o problema de um framework não-POJO como o que você citou eu e toda a comunidade já conhecemos há alguns anos, por isso surgiram Spring, EJB3.0, Java EE 5.0, Struts 2, etc, etc, etc

Então todo conceito de POJo é overkill para você Recomendo fortemente a leitura dos livros de Rod Johnson, Eric Evans e Bruce Tate.

Isso merece uma explicação com um pouco mais de contexto. Page-Jones define os domínios de um sistema (nada aver com Domain Model), entre eles temos Negócios e Aplicação.

O código de negócios seria aquele que mapeia as entidades do mundo real. O código da aplicação mapeia as operações que aqueles casos de uso realizam sobre estes objetos.

Os tais módulos dificilmente (a menos que num plugin para MVC, persistência ou sei lá) saem destes dois domínios e estes são os mais importantes apra uma aplicação.

Bem, como código importante ele deve ser testado, certificado, facilmente refatorável, flexível e uma outra pá de adjetivo. Se você vincula este código com um framework você perde boa parte destes.

saoj:

fabgp2001:

Achei que era so eu que nao tinha gostado daquela parada.

Soh falta agora apresentar motivos ne?

Vc prefere se atrelar a uma classe herdando ela e ganhando de presente um monte de funcionalidades ou usar anotacoes atrelando do mesmo jeito?

Acho que temos um anti-pattern aqui. Pegaram a heranca como bode-espiatorio…

A herenca ali naquele caso não passa de um heranca pra economia de codigo o que eu acho feio e não gosto. Outra coisa porque AbstractModule tem que ser abstrata? Porque nao fazer igual o Hibernate faz com a classe Configuration?

Module module = new Module() module.bind(Foo.class).to(FooImpl.class).in(Scopes.SINGLETON);

Outra coisa ao invez de obrigar a fazer isso podiam ter uma configuracao automatica tipo o VRaptor faz com os components.

Questao de opinao.

]['s

Unica explicacao para nao querer atrelar nada a sua action seria porque vc esta codificando seu modelo de negocios DENTRO da action, o que eh totalmente errado.

A action nao eh codigo importante, na grande maioria das vezes eh apenas uma ponte para o modelo de negocios. E nada te impede de testar uma action, estando ela atrelada ou nao a uma classe pai. Isso jah foi mostrado, provado e discutido um milhao de vezes, mas enfim…

E um modulo de configuracao programatica nao existe para ser testado. Nao faz o menor sentido testar ele assim como nao faz o menor sentido testar um arquivo properties ou XML. :roll:

De novo. Action e Configuracao eh uma coisa. Modelo de negocios, DAOs e entidades sao outras completamente diferentes.

Action apesar de algo burro e simples, vc pode testar FACILMENTE E SEM QUALQUER PROBLEMA, mesmo que ela seja atrelada a uma classe pai.

ApplicationManager nao foi feito para ser testado, mas se o cara eh caxias entao ele pode testar tb e publicar um blog interessante sobre isso. “Como testar se sua configuracao tem bug!”

O problema do Struts nao era por que ele extendia uma BaseAction, eu e todos da comunidade sabemos que os problemas eram outros…

Mas eh um questao subjetiva, uma discursao sobre teoria e pratica.

Olha que engraçado, herdar não era problema para o Struts? A apache discorda de você:

E que comunidade é essa que você frequenta? Uma busca no Google traz uma mar de resultados…

http://mail-archives.apache.org/mod_mbox/struts-dev/200503.mbox/<[email removido]>
http://raibledesigns.com/rd/entry/how_do_you_get_around
http://72.14.209.104/search?q=cache:9LMizODEbkYJ:strecks.sourceforge.net/docs/Struts-Extensions-20032006.pdf+struts+problems+pojos+inheritance&hl=en&ct=clnk&cd=20

E quais os problemas reais? XML?

Releia a parte de domínios acima, consulte a bibliografia ou pelo menos dê argumentos, por favor.

Segundo seu pensamento TDD é uma burrice sem tamanho, já que vai querer que você pense nas actions com testes antes de implementação. Além do que a grande vantagem em definir actions como POJOs é que você pode utiliza-las fora do framework, logo elas não rpecisam ser burras.

Se minha Action é um POJO, completamente testado e que nem sequer precisa seguir o padrão Command por que eu não posso simplesmente fazer minha aplicação web conversar diretamente com o Service Façade?

Ver resposta acima.

Claro, por exemplo testar uma Action Struts é muito fácil, inclusive por isso toda a comunidade java continua seguindo este modelo e rindo de coisas inúteis como o Spring.

O que esse tal módulo faz, afinal? Bind de componentes para nomes? Isso não é papel do container?

Para mim mais uma vez você está ignorando a evolução de anos de uma plataforma, voltando para uma característica que sempre foi um dos grandes problemas de EJB 1.x/2.x, Struts e todos os ‘frameworks de primeira geração’.

Toda essa teoria bonita vai ter um preco: complexidade.

Se vc quer criar uma aplicacao web totalmente desacoplada de qualquer framework e totalmente acoplada a um monte de annotations, se vc quer criar um modelo de negocios que por magica (magica = um monte de anotations e convencoes loucas) ele se torne uma aplicacao web, vc pode.

O que vc vai ganhar com isso alem de tirar onda com os amigos de que sua aplicacao eh a mais puritana possivel e segue os conceitos do livro de patterns de Michael Zimmerman e Oswald Anthony? Muito pouco! Isso na minha opiniao.

Vamos a pratica que eh o que interessa no final das contas, ou nao?

public class MinhaActionTotalmentePura {


       public void execute() {
      
             // como pego a session aqui dentro?

             // como pego o application aqui dentro?

            // como sei se o metodo foi POST ou GET ?

           // Como faco se nao sei quais os parametros que virao, e preciso pegar a lista de todos os parametros e itinerar sobre eles?

       }

}

Claro que dah para fazer tudo isso via magica, convencoes e annotations. Eu acho que o preco a pagar eh o aumento da complexidade e o que se ganha no final das contas eh pouco, visto que o seu modelo de negocios vai estar em outro lugar e nao ai dentro.

Mas isso eh apenas a minha opiniao e entendo e aceito que outras pessoas poderao pensar diferente. Estou apenas me apegando ao principio de que SIMPLICIDADE eh o mais importante. Outras pessoas nao necessariamente precisam concorda com esse principio.

Pelo menos foi legal ver que nao estou sozinho, que o Guice tb usa um esquema parecido de configuracao programatica.

Fala Amigo, tudo bem?

Então, estou acompanhando essa discução e vi essas duas mensagens que vc postou… eu entendi errado ou vc disse na primeira que codificar o modelo de negócios dentro da action é errado e na segunda vc disse o inverso? Sem sacanagem, só não entendi mesmo… oque vc quis dizer na primeira e oque vc quis dizer na segunda?

[]'s

Desdenhar um argumento com “teoria bonita” só mostra que não vale a pena continuar esse pseudo-debate.

Desprezar décadas de teoria de ciência da computação já é ridículo.

Ignorar o fato de que existem zilhões de ferramentas que fazem tanto sucesso que revolucionaram a maneira como as coisas são feitas (Spring, RoR, Hibernate, EJB 3, etc.) é simplesmente lamentável.

Chamar isso de complexidade sem qualquer argumento é simplesmente uma prova de que você nunca viu ou testou a fundo estas plataformas. Coloca SIMPLICIDADE em caps não vai trazer qualquer argumento ao debate alémd e chamar a atenção para uma não-verdade.

As suas perguntas no trecho de código mostram que ainda te falta compreender como as coisas funcionam em Injeção de Dependências (como eu obtenho recursos em DI?). Acreditar que uma action deve saber o que é POST ou GET é sintoma de incapacidade de abstração.

Como não foram dados quaisquer argumentos que não ‘isso é complexo, bobo e feio’ eu paro por aqui. Você é um desenvolvedor excelente, sérgio, mas cuidado com NIH, está atingido níveis patológicos.

“visto que o seu modelo de negocios vai estar em outro lugar e nao ai dentro.”

Eu quiz falar que o modelo de negocios vai estar encapsulado em outro lugar fora da action. Sua duvida eh pertinente sim, visto que isso eh meio ambiguo. Para melhorar poderiamos falar assim:

“a action usa o modelo de negocios mas nao o implementa. O modelo de negocios estah implementado fora da action e eh um codigo a parte e nao dependente/atrelado a nada do framework.”

Logo o meu ponto eh que a action eh burra e so faz chamadas para dentro do modelo. O modelo sim eh que eh a alma do negocio…

pcalcado:

Desdenhar um argumento com “teoria bonita” só mostra que não vale a pena continuar esse pseudo-debate.

Nao desdenhei. Teoria eh teoria. Pratica eh pratica. Eu gosto mais da pratica. Gosto meu…

Nao desprezei, sou apenas contra muita teoria que na pratica nao se aplica ou acaba virando overkill. Famoso anti-pattern.

Nunca ignorei. Por que vc nao incluiu ai Struts 1, Tapestry, JSF, Seam, Wicket, WebWork, Spring MVC. etc? Quando o Mentawai surgiu em Junho/2005 alguns desses frameworks estavam em voga. Dos que vc falou apenas RoR eh um framework web, so que por azar em outra linguagem.

Quem tinha que argumentar era vc. Eu consigo fazer isso de maneira bem simples com o Mentawai. O meu ponto era que fazendo tudo via annotation, magica, metafisica, etc e tal fica bem mais chato e complexo. Vc poderia ter mostrado como se faz? Se eh simples vc deveria ter respondido com o pe nas costas, mas se vc preferiu responder assim, entao talvez nao seja tao simples.

Eu diria que nao. O time do Mentawai tem feito um excelente trabalho e o framework eh reconhecido por pessoas de gabarito. Se o cara do OpenSolaris falou que Spring + WebWork eh muito complexo e heavyweight e migrou o site dele para Mentawai, entao eu vou dar um voto de credibilidade para ele. (Mas complexo que um sistema operacional nao deve ser, neh?)

Deu um exemplo pratica e vc deixou eu e um monte de gente na duvida de como fazer.

Quer melhor argumento do que um framework utilizado por muitas pessoas que geralmente enviam mensagens e emails elogiando e incentivando o projeto? Mata-se a cobra e mostra-se o pau e nao apenas conta-se uma historia.

Sera que os caras do Google fizeram esse Guice baseado em configuracao programatica como o Mentawai tambem nao compreendem isso? Fiquei feliz de ver que o Guice se parece bastante com o suporte do Mentawai a DI / IOC (pra quem estah chegando agora vejam a comparacao na primeira pagina do topico). Se estamos fazendo coisas parecidas com as coisas que o pessoal do Google estah fazendo, entao as chances sao boas de estarmos no caminho certo! (Ou nao? Eles viajaram e o GoogleAds feito com isso tem serios problemas?)

pcalcado:

Você é um desenvolvedor excelente, sérgio, mas cuidado com NIH, está atingido níveis patológicos.

Obrigado! Vc tb como ficou visto pelos seus argumentos aqui. O seu problema acho que eh uma falta-de-vontade de dar o braco a torcer para o Mentawai. Algo assim: "vou usar toda a minha inteligencia e capacidade para desmerecer e desacreditar esse projeto’’.

Tudo bem. Sairao atritos porque eu tb gosto de argumentar. No final das contas acho que todos ganham com o debate.

Ja estou ate com vontade de implementar um suporte a actions sem interface e sem heranca. Nao porque eu esteja convencido de que esse eh o caminho, mas para ser menos um pedra a ser tacada no nosso projeto. Sendo opcional, mal nao pode fazer…

Eu so acho que voce deveria aceitar mais a opiniao alheia mentawai nao e o kill-framework e vc sabe disso (eu espero) . Entao relaxa e curta o momento.

Se eu tivesse esse seu pensamento negativo e derrotista realmente ele nao seria e nunca poderia ser o kill-framework. Esse seu comentario foi esquisito, mostrou uma certa preocupacao em jogar pra baixo. A melhor e mais honroso nesses casos eh ficar neutro, principalmente quando nao se apresenta nada melhor e goza-se com o pau dos outros: no caso qualquer outro framework.

Nada eh ou deve ser a palavra final, mas com os comentarios positivos que temos recebido em relacao ao framework, vemos que estamos fazendo um excelente trabalho. E isso apenas nos motiva a trabalhar mais, independente dessa sua vontade louca de ver a coisa pegar fogo. Jogar pra baixo para aparecer eh uma caracteristica pessima. Principalmente quando ela vem acompanhada de nenhum argumento. O Phillip quer ver o projeto fazer agua, mas pelo menos tem bagagem para argumentar e debater sobre tudo isso… Acho que o pessoal do GUJ estah gostando do debate… Ou vc prefere o help-desk?

============================================
Leia essa pagina aqui e curta o momento., Fernando!

Jogar pra baixo nao, apenas mostrar que voce as vezes eh chato pra caramba em aceitar o que os outros pensam.

Quanto a gozar-se com o pau dos outros … eh bom, e ainda eles me pagam beeeem pra isso
Minha praia nao eh frameworks web eu acho que a gente tem coisas mais interessantes pra se fazer do que ficar apenas dispachando actions pra la e pra ca.

Quanto a curtir o momento, me desculpe mas isso nao me impressiona.

Bha Sergio na boa.

Será que nao da pra acalmar com o Menta no topico?

A discucao devia ser com um framework de DI, nos sabemos que o Menta tem isso, mas ele nao tem esse proposito. Eu mesmo ja tentei desvincular a discucao aqui pra nao falar do Menta e sim do fremawork em si, mas nao adianta.
O brabo é que sempre que alguem fala mal do Menta tu coloca essa pagina do que as pessoas acham dele. Sinceramente eu respeito muito o trabalho do Menta e tu sabe disso, mas enche o saco esse negocio.

Ps.: Espero que nao leve pro lado pessoal.

]['s

Ufa, achei que era so eu que nao gostava disso.

]['s

Gracas a Deus que eu posso colocar essa pagina neh… Pagina sobre o Lohis, Space4J, eu nao mostro, porque nao tem… Vc nao deveria ficar irritado com isso…

Foi mal se vc nao gostou da discussao, mas pelo numero de acessos acho que muita gente no GUJ gostou da discussao…

É desisti.

]['s

eh, daqui uns dias o pessoal posta um offtopic falando de notebook e vc vai responder comparando o mentawai com processador dualcore.

( basicamente o que voce fez nessa thread )

fmeyer:

eh, daqui uns dias o pessoal posta um offtopic falando de notebook e vc vai responder comparando o mentawai com processador dualcore.

( basicamente o que voce fez nessa thread )

Acho que muita gente gostou do topico e dos argumentos. Relaxa e curte o momento, Fernando.

saoj:

Foi mal se vc nao gostou da discussao, mas pelo numero de acessos acho que muita gente no GUJ gostou da discussao…

Barraco sempre fez sucesso no Brasil.

E ou se volta pro assunto da thread ou cabou-se poraqui. Roupa suja lavem por msn.

saoj:

fabgp2001:

O brabo é que sempre que alguem fala mal do Menta tu coloca essa pagina do que as pessoas acham dele.

Gracas a Deus que eu posso colocar essa pagina neh… Pagina sobre o Lohis, Space4J, eu nao mostro, porque nao tem… Vc nao deveria ficar irritado com isso…

Foi mal se vc nao gostou da discussao, mas pelo numero de acessos acho que muita gente no GUJ gostou da discussao…

O que irrita é seu egocentrismo, transformou isso aqui em mais um “tópico em que o Sérgio fica batendo na mesma tecla de como seu framework é maravilhosamente bem-feito e bla bla bla”. Parece uma necessidade muito grande de auto-afirmação. Fico me perguntando porque desenvolvedores de outros frameworks não fazem a mesma coisa que você faz.

Pergunta pra eles e nao pra mim…

O topico foi bem distribuido e equilibrado com argumentacoes opostas minha e do Phillip.

Vc deveria ter participado ao inves de ficar irritado.

Leia o topico novamente e verah que o topico nao foi soh sobre o Mentawai. Houve discussoes boas com pontos contra e a favor…

Que tipo de discussao vc gosta?

Até um ponto a discussão estava interessante, discussões sobre pontos de vista sempre são interessnates.

Pelo q entendi o Guice é um framework DI, q não está acoplado a web, o qual utiliza annotations.
Então por um lado não tem muito o q comparar com o mentawai, pois este é totalmente integrado a web (request/response, actions, etc), se bem q eu gostaria de ver o DI do menta desacoplado da web … aí a comparação rolaria legal, rs