| Autor |
Mensagem |
|
|
"A lógica tem que estar no banco de dados."
"Isso não é uma gambi...é um artifício."
"Quando ficará pronto?"
"Quantos % pronto?"
"AJAX é melhor que javascript?"
"Recurso"
|
 |
|
|
louds wrote:
Kenobi wrote:Parabéns Louds pela notícia, não sei se ainda estás envolvido com o projeto, mas realmente é um grande feito 
Continuo sim envolvido com o projeto e sem planos de mudar.
Poxa, muito legal saber que o Mono está melhorando os recursos, trazendo novidades...
e ainda por cima um Brasileiro trabalhando num projeto importante no mundo do código livre.
Só falta agora baixar e testar as novidades.
Parabéns Louds.
|
|
|
|
Olá Alessandro, bom dia.
Vou te responder:
Alessandro Lazarotti wrote:
jonataswingeter wrote:"(Nem pense usar um IceFaces ou RichFaces...aí mesmo vira uma bomba...
péssima qualidade na concepção destes frameworks de componentes). "
Discordo totalmente. O Richfaces/A4J é uma excelente suíte com uma excelente qualidade (aliás, o uso muito). Conversando com o Ed Burns depois do TDC deste ano, perguntei se ele gostava do IceFaces (já que eu, o Vinicius Sengers e outros estavamos batendo uma papo sobre esta suite e suas incompatibilidades, entre outras coisas). O Ed foi enfático em afirmar que gosta do Icefaces e acha uma ótima suíte... suas imcompatibilidades com outros componentes (como com o a4j, por exemplo), é decorrentes da não especificada implementação AJAX para componentes JSF (situação corrigida para a versão 2.0) e de nada tem haver com qualidade do framework.
Já usei bastante o RichFaces e A4J. Obviamente ele tem sua qualidades. Minha intensão não é "sentar a lenha" ou criar flame, fique tranquilo. Eu digo que o que ele se propõe em fazer, deixa muito a desejar ainda.
Por exemplo, o nível de tráfego de dados das árvores dos componentes (isso é mais culpa do JSF) e o browser; A qualidade da programação JavaScript (verbosa e muitos bugs)...aquela DataTableScroller é um exemplo; Integração com o Facelets funciona bem para telas simples. Basta aumentar a complexidade que começa a surgir os problemas. Aliás, não gosto do Facelets também. Faz uma grande gambiarra no response (usando NekkoFilter e outros) para converter ao XML e ser lido pelo Browser...Javascript e XHTML não se dão muito bem, que diga o Firefox.
Alessandro Lazarotti wrote:
jonataswingeter wrote:Seam tem lá suas qualidades...mas é somente um precursor do WebBeans.
A Stack Solution oferecida pelo Seam "contém" os elementos que estão na JSR do WebBeans, mas ele incorpora muuuuuitas outras features. Desde sua Api "Persistence" Framework, passando por BPM, segurança e pageflows, isso de nada tem haver com webbeans.
Sim, o Seam tem suas qualidades. Eu acompanho o Seam e ele surgiu como um teste para a concepção do WebBeans e para corrigir as burradas do JSF, é claro.
Alessandro Lazarotti wrote:
jonataswingeter wrote:Porque não gosto do WebBeans? Porque é uma mescla de JSF + EJB + JPA. Um projeto pode não precisar de tais tecnologias, e aí você vai ver muito
projeto utilizando essas coisas aí que não precisariam (já existem muitos).
Hã? E pq não você não teria com o Seam: GWT + POJO + Hibernate ? Ou Flex + Spring + JPA ? O Seam não manda em como você vai montar sua arquitetura...
Se eu uso GWT, posso fazer modelar sem precisar do Hibernate...não vem tecnologias on-demand.
Flex? Flex é tecnologia de visualização. Nada tem haver com Spring + JPA.
Seam realmente não manda como você vai usar sua arquitetura, desde que você use JSF, EJB... E realmente espero que o Seam continue assim...porque se a idéia de transformar em um framework agnóstico de tecnologia de visualização vingar, aí será o fim (JIRA com 3000 tickets por dia).
A idéia é quanto menos você tiver, mais você ganha.
Abraço,
|
|
|
|
Fabio Kung wrote:
jonataswingeter wrote:Porque não gosto do WebBeans? Porque é uma mescla de JSF + EJB + JPA.
Essa parte não entendi. Em que sentido ele é uma mescla dessas três coisas que fazem coisas totalmente diferentes?
Se você dissesse que é uma mescla de guice, spring ioc e picocontainer eu até entenderia (e concordaria)
Fábio, bom dia.
Desculpe ser minimalista em minhas colocações, é devido ao tempo mesmo.
Eu acompanho a JSR-299 a um tempo...minha colocação foi em relação ao resumo dessa frase:
The purpose of this specification is to unify the JSF managed bean component model with the EJB component model, resulting in a significantly simplified programming model for web-based applications.
Abraço,
|
|
|
|
Gilliard,
bom dia.
Preciso correr aqui num projeto, mas serei breve.
Não quero malhar livremente o JSF pois sei que vem acalhar em muitos projetos.
Já tive muitos problemas com a parte de browser (comportamentos) devido
a má codificação de scripting, falta de testes neste sentido.
Utilização de Ajax. Muitas requisições são feitas no ciclo do JSF quando se usa,
por exemplo, um A4J. Tem muita abstração na API que a torna a implementação
(qualquer uma) verbosa. A concepção do ciclo de vida é muito extensa (6 fases)
e quando se utiliza ajax nisso aí, exige-se muito cuidado. Aí é melhor você partir
para um DWR, que em contrapartida, exige maior codificação, com um pouco mais
de controle. (Nem pense usar um IceFaces ou RichFaces...aí mesmo vira uma bomba...
péssima qualidade na concepção destes frameworks de componentes).
Converters básicos que deveriam ser inerentes (converter de objeto para SelectItem, ex).
Aí fizeram a implementação no Seam pra resolver as coisas "básicas" que deveriam
ter no JSF, como escopo de conversação.
Outra coisa, JSF não aguenta alta demanda. Com o Seam junto talvez ajude no quesito memória.
Já vi tanta aplicação feita em JSF que em pouco tempo já levantava um "PermGen error" ou
"OutOfMemory Error". Claro que aí caímos na qualidade da aplicação, porém, o framework
em si já deveria prover recursos que ajudassem o desenvolvedor a tomar o caminho correto
(como no Seam).
Eu nem falei dos bugs...pois isso existe em todo framework, mas no JSF RI da Sun tem bastante.
No MyFaces nem se fala...Já ajudei o time da apache com bug tracking.
Seam tem lá suas qualidades...mas é somente um precursor do WebBeans.
Porque não gosto do WebBeans? Porque é uma mescla de JSF + EJB + JPA.
Um projeto pode não precisar de tais tecnologias, e aí você vai ver muito
projeto utilizando essas coisas aí que não precisariam (já existem muitos).
Na década de 90 tinhamos os problemas de Client-Server. Fomos para web, e surgiu
os problemas dos browsers, separação de camadas, etc.
Veio o AJAX, trazendo conceitos inovadores, porém, trouxe outros problemas.
Em meados de 2009, estamos voltando ao conceitos de mais de 10-15 anos atrás.
Tá tudo complicado demais. Precisamos de simplificações (a arquitetura
AMIDAS era bem melhor que muita coisa por aí).
E pra finalizar: Menos significa mais.
Valeu,
|
|
|
|
Espero que melhore a API e sua implementação (Sun RI).
Confesso que já nem tenho tanta vontade de vê-lo, diante de tanta
coisa ruim que já vi nesse framework. Obviamente é fácil atacar pedras,
por isso quero ver com calma.
Quanto ao WebBeans, prefiro nem comentar.
|
|
|
|
- Java e JavaScript;
- Haskell;
- Scheme, Erlang;
- Não conheço o futuro...talvez a minha própria
|
|
|
|
Vc tocou num ponto crítico. Persistência de dados é uma área onde apesar de haver concorrência há medalhões como Hibernate e ActiveRecord. Dá tranquilamente para utilizar um framework web sem Hibernate e RoR sem ActiveRecord. Mas não dá para recomendar isso devido ao nome (merecido!) que Hibernate e ActiveRecord possuem.
Saoj,
Dá pra recomendar sim!
Particulamente não sou muito fã de hibernate. Para você ter um desempenho razoável e boa modelagem (questionável), é necessário deixar o controle na mão do Hibernate. E como a maioria das aplicações possuem a modelagem independente, já fica difícil usá-lo, sem contar ainda que para ter sucesso com ele, você tem conhecer MUITO do framework, entrar em picuinhas. Dentre essas e outras, prefiro o bom e velho JDBC. Nada melhor
que ter o controle da aplicação. 
ORM não é fácil...tende a ser uma gambiarra.
Abraço,
|
|
|
|
Olá pessoal.
Eu sempre fui a favor de inovação, mas eu realmente questiono: Mais um MVC?
Eu tenho a opinião de que quanto menos você depender, melhor. Agora, se você precisa
inovar em seu projeto, usar algum modelo aperfeiçoado, e precise desenvolver um framework
novo ( ou usar um inovador), sou a favor. O problema é que não tem surgido frameworks Java Web
que trazem inovação e ao mesmo tempo simplifiquem as coisas.
O que temos no mercado é, em sua grande maioria, um remendo de código, mesmo sendo
definido pelas grandes corporações.
Abraços,
|
|
|
|
Olá Pessoal,
Visualizei muitos comentários interessantes postados até aqui.
Não sabia que o RoR pretende tomar o lugar do java...
Então,
A discussão SpringXEJB é muito mais que uma argumentação de pontos
tecnológicos... é praticamente um debate religioso. Tanto o EJB3
quanto o Spring têm pontos interessantes e atendem à determinadas situações.
Um dia a comunidade de desenvolvimento software talvez venha a entender
que a tecnologia é útil para resolver problemas tecnológicos de algum
projeto específico. Ponto. Primeiro é necessário conhecer o problema,
depois propor uma solução. Isto não pode ser invertido.
Eu tenho minhas preferências em termos de tecnologia baseado
naquilo que obtenho através da experiência, isto é, no dia a dia
descubro aquilo que é bom, pontos positivos e negativos, etc.
Todo framework e linguagem possuem pontos fortes e fracos...
Quem pode me dizer alguma solução perfeita? Se disser, está mais para uma
crença que um fator epistemológico.
Spring, EJB3, RoR nunca serão a última bolacha do pacote. Isso não existe.
Mas sobre o Spring X EJB:
Porque motivos eu preciso distribuir uma aplicação se eu nem sei se num futuro
tão próximo precisarei de tal recurso?
Usar EJB simplesmente para ter uma arquitetura n-camadas é plausível? Mesmo
que não seja distribuido? Será que é a única solução?
Ah...posso querer montar um cluster no futuro, e com EJB fica mais fácil...
Tenho que ter DI na minha aplicação? é obrigatório? vai facilitar alguma coisa?
Farei AOP? Realmente preciso ter um mentor transacional?
Pois é...tudo depende.
Sobre os argumentos do pessoal:
Concordo com o Leonardo sobre o EJB, a interface deveria ser comum. Deveria permitir
extensão e não obrigar. Gosto mais da idéia de usar um proxy para
aumentar/diminuir visibilidade.
Por enquanto é isso.
Att.,
|
|
|
|
Pessoal,
Se o Java faz autoboxing a todo momento, ou se a HotSpot pára a todo instante, não importa agora...
O que estou vendo aqui é uma discussão inútil, pois é duelo de forças.
Criem um tópico sadio, discutam os pontos, e com certeza vai agregar valor pra comunidade.
Vai uma sugestão:
HotSpot GC step-down ou Jikes GC Cyclic-Reference?
E sobre o meu comentário de humildade, foi pra todo mundo, inclusive pra mim...ou vocês acham que não dá uma tentação de "esbanjar" conhecimento?
[]'s,
|
|
|
|
Cada dia que passa tenho a impressão que programadores seniors têm fortes tendências
de se acharem deuses da computação e sairem pisando nos "seres inferiores".
Eu admiro mesmo ver um programador senior com 15 anos de experiência dizer: "Eu ainda estou aprendendo".
|
|
|
|
Olá pessoal.
primeiro, estamos realizando discussões num fórum virtual, onde as frases podem ser mal entendidas devido a subjetividade implicita, já que não temos como prever "expressões físicas e corporais". Contando com isto, devemos ter o cuidado para não agredir verbalmente e nem realizar certos tipos de brincadeiras a não ser que a pessoa em questão seja íntima, o que simplifica as coisas.
segundo, a melhor coisa é refletir, perdoar e esquecer as discussões aqui geradas. Bola pra frente.
Terceiro, sobre Javascript:
JavaScript é OO baseado em protótipos e como vivemos num mundo real: toda linguagem tem suas vantagens e desvantagens.
As diferentes técnicas para se programar OO com JS nos permite usar a melhor abordagem de acordo com a necessidade. Por exemplo: Não vou criar métodos nested numa classe se possuo muitos métodos complexos, o que afetaria a construção deste objeto, gerando overhead. Mas para classes base, menos específica ou logicamente mais simples, vale a pena.
Sou programador JS há 7 anos. Adoro este linguagem, no entanto, acho difícil uma progressão rápida e robusta sem uma adoção padrão por parte dos fabricantes de browsers. Obviamente não me refiro ao Firefox ou Ópera.
Gostaria muito de ver uma padronização. O que mais afeta o programador é a falta de transparência nos diferentes browsers, comportamentos específicos, implementação mais custosa (baixo desempenho), etc. Aí o programador é obrigado a usar um toolkit para facilitar, e depois de um certo tempo usando, ele percebe que a amarração é tanta que ele precisa largar o toolkit adotado...Obviamente existes toolkits interessantes, como ExtJS, no entanto, não existe a "bala de prata"
no mundo JS. É prototype, JQuery, DOJO, Scriptacolous, Ext...todos tem defeitos (em menor ou maior escala).
Quarto:
Sobre a pergunta específica do tópico, não me restrinjo a tecnologias, mas também a assuntos:
1 - Grid Computing. Ver produtos como Terracotta ou Gigaspace. Isto sim é um conceito em evolução
e que vale a pena estudar, ainda mais com os núcleos aumentando.
2 - Relacionado ao primeiro, Concorrência. É um tópico que o Java precisa despontar de vez.
Temos muitos avanços, porém, nada em especial. O que é uma coisa simples em Erlang (Thread-safe)
em Java é um tema complexo, devido a questão de Object-sharing.
3 - GWT. Este bixinho veio com um conceito muito interessante. Quem ver o "core" do negócio
vai perceber que a idéia dele é muito boa, ainda mais para o programador final "end-user".
4 - Scripting server-side. Só olhar Groovy, JRuby...Rhino.
5 - Java Applet. Calma, é brincadeira!! Não consigo pensar em alguma coisa agora, então fica
sem resposta.
Bom pessoal, por enquanto é isso.
[]'s,
|
|
|
|
Rodrigo,
Concordo em gênero, número e grau.
Tem muita gente usando RUP para documentar...
Talvez muitas empresas estejam interessadas em vender "documentos" e "especificação" que um produto de qualidade.
Por isto gosto do SCRUM: realmente simplificar...
Att.,
|
|
|
|
paulovittor23 wrote:
Fala Davy..
como descrito nas novas funcionalidades do Seam 2, usar ou não o JSF passa a ser opcional..
Removing the JSF dependency
The Seam core has been completely overhauled. In addition to extensive packaging changes, Seam has now been de-coupled from JSF so that it can be more easily used with other web frameworks. We've included some experimental GWT integration that shows how this might work. Want Seam with your favorite web framework? We've opened the doors for the ambitious.
Paulo,
Como escrevi em outro post, isto é contraditório com a primeira versão do Seam e com o Web Bean JSR 299.
EU não entendo o porquê querer abranger qualquer framework...Se diferentes frameworks tem diferentes comportamentos em seu core.
Só se eles reescrevem a JSR 299 Web Bean. Digo isto pois a JSR 299 se focaliza no JSF e o Seam 2.0 quer ficar independente do JSF...
Se você olhar, o intuito desta JSR é padronizar o JSF como framework, com os recursos do Seam.
Att.,
|
|
|
|
|
|