To acompanhando os tutoriais de JSTL que estão vindo na JavaMagazine…
qual a opinião de vcs sobre o JSTL?
Muito conveniente e bom, mas chegou em hora errada. Há outras soluções por aí (como velocity) que já estão consolidadas e fazem as mesmas coisas que você poderia fazer com JSTL.
mas tipo… se eu me famializar mais com o JSTL, ele e o velocity competem cabeça a cabeça ou um é muito melhor que o outro?
se você utilizar JSP com JSTL você tem todas as vantagens da tecnologia JSP incluindo muitas TagLibs disponiveis no mercado, coisa que não existe para um velocity por exemplo
se você utilizar velocity ou outra tecnologia de templates você não tem os problemas provindos da JSP, como por exemplo, um outro desenvolvedor detonar com o teu MVC abrindo uma conexão com o banco direto de uma JSP para fazer uma consulta.
ainda prefiro utilizar JSPs a outra template library, pela extrema flexibilidade e recursos disponiveis no mercado
os problemas da flexibilidade em excesso são facilmente contornaveis com uma boa equipe que sabe que deve utilizar as JSPs apenas para VIEW 
O Velocity é muito mais maduro e separa muito bem as camadas MVC, além de poder ser usado em qualquer solução que use templates (documentos de texto, XML, Rich Text etc). 
A SUN está tentando tirar o atraso…
Na Java Magazine no. 6 tem uma matéria sobre Velocity, escrita pelos nossos amigos Paulo Silveira e Rafael Steil. E, segundo eles, o Poseidon UML usa Velocity para a geração do código a partir dos diagramas UML. 
A JSP 1.2 vem com as TVLs (TagLib Validators), com elas é possível restringir os recursos JSP usados e também as taglibs que podem ser importadas. Com isso você limita as possibilidades de outro desenvolvedor, fazendo com que ele não detone o MVC.
Eu estou trabalhando com a JSTL e gostando muito, apesar que nunca estudei de verdade o Velocity. Atualmente recomendo sua utilização…
Gustavo Guilherme BacK
Falei ultimamente com o Felipe Leme, e ele mostrou pra mim esses TLVs. Realmente da pra fazer o JSP ficar bem restrito a View apenas.
Sou um pouco radical com essas TLVs e outras “novidades”. Pra mim, isso eh remendo de uma coisa que nao funciona.
claro que se vc pode usar umas taglibs power, provavelmente compensa.
[]s!!
[quote=“dukejeffrie”]Sou um pouco radical com essas TLVs e outras “novidades”. Pra mim, isso eh remendo de uma coisa que nao funciona.
claro que se vc pode usar umas taglibs power, provavelmente compensa.
[]s!![/quote]
Hum… você já ouvi falar de um cara chamado Darwin e uma tal de teoria da EVOLUÇÃO???
Sinceramente, é ridículo pensar que as coisas não podem ser melhoradas, e que as deficiências não podem ser corrigidas. Se isto fosse verdade não haveria o linux com seus releases, nem o windows com seus updades, nem Unix, XML, JAVA, SQL… nossa… praticamente tudo na informática nasce com algumas defeitos quem são sanados conforme seu uso e experiência… acho que você deveria repensar esse seu conceito.
Gustavo Guilherme BacK
Particularmente, não acho que se deva comparar Velocity com JSP. O Velocity tem um propósito de template engine que vai além de transformar páginas html. Acho o velocity bem mais útil para se trabalhar por exemplo com geração de códio. Enquanto o jsp é aplicado na camada de apresentação, possui o suporte das tags do JSTL, tags que vc pode criar (gosto muito disso no jsp) e o JSF que vem por aí. Trabalhando em um sistema MVC jsp é muio legal como view, e muito poderosa, além de sistemas de templates tb criados para ele como o Tiles. Lógico que tem muita gente que faz gambis acessando o banco direto da view, mais isso é de quem ainda não conhece uma maneira legal de trabalhar com jsp.
Uma coisa que gosto no mundo Java é justamente a possibilidade de escolha. Seja com jsp, Velocity, Cocoon, WebMacro … a escolha é sua e o bom uso da tecnologia é de sua responsabilidade.
[quote=“back”]
Hum… você já ouvi falar de um cara chamado Darwin e uma tal de teoria da EVOLUÇÃO???
Sinceramente, é ridículo pensar que as coisas não podem ser melhoradas, e que as deficiências não podem ser corrigidas. Se isto fosse verdade não haveria o linux com seus releases, nem o windows com seus updades, nem Unix, XML, JAVA, SQL… nossa… praticamente tudo na informática nasce com algumas defeitos quem são sanados conforme seu uso e experiência… acho que você deveria repensar esse seu conceito.
Gustavo Guilherme BacK[/quote]
O que o Tiago quis dizer eh que isso veio como um remendo, pq em JSP vc podia sair abrindo connection pool, e ainda pode Isto eh, vc tem a opcao de restringir, mas ainda pode nao restrigir, no jsp2.
tambem acho um remendao. mas melhor q nada.
Tai uma questao mto interessante - quando é remendo e quando é evolucao? Eu vejo uma razao simples pra maioria das tecnologias Java ter se tornado pequenas colchas de retalhos ao longo do tempo: compatibilidade com versoes anteriores.
Isso restringe absurdamente as possibilidades, sendo que, se vc nao pode consertar as cagadas mantendo as interfaces e a compatibilidade com as especificacoes anteriores, vc tem que dar uma alternativa (veja o caso do AWT, por exemplo).
No caso do JSP, nao eh possivel acabar de vez com o problema de poder tornar seus JSPs poderosos demais, pq isso quebraria um monte de aplicacoes existentes. Entao, o que vc faz? Fornece uma alternativa, que seria mais ou menos o caso do JSTL e Java Server Faces, e ainda por cima da um jeito de botar lá uma opcao pra quebrar a compatibilidade com sistemas antigos que foram mal-feitos.
Agora, advinha soh o que vai acontecer em times desorganizados ou com prazos muito apertados? Essa opcao (os TLVs) vao ser desligados na primeira chance… :roll:
Em compensacao, de uma olhada no Velocity. Basicamente tudo que o time do Velocity faz hoje em dia é consertar alguns raros bugs que aparecem de vez em quando e negar a inclusao de novas features. O Velocity nao deve e nao quer crescer alem do que ele ja eh hoje - uma linguagem simples e flexivel pra geracao de todo tipo de texto, ponto final.
pessoal, não sou um usuário de velocity não, mais acho o velocity perfeito como gerador de código sendo adequado para projetos como ArgoUML, XDoclet etc. Substituindo o jsp como view ele lembra webmacro, TierServlet e outros desse estilo. Particularmente prefiro jsp na view mesmo e gosto da JSTL, Tiles … agora não concordo com a crítica de que o jsp é ruim pq é poderoso, bem todo mundo sabe que um jsp vira um servlet então caramba, é lógico que vc tem acesso a tudo que um servlet faz, e exite a escolha de se usar isso ou não. na JSTL por exemplo existem as tags de SQL, que eu nunca vou usar na minha vida, porém elas existem usa quem quer. Muito se fala “com o velocity não se faz isso”, mais na realidade é pq ele realmente não pode fazer, pq ele é um parser, um template engine e só. Mais quero deixar claro que não tenho nada contra o Velocity, é só um ponto de vista.
Este meu poste se resume em FLEXIBILIDADE.
JSP deve ser uma linguagem de script que tem o poder de se integrar a outros recursos de JAVA para se tornar poderosa, ou simplesmente realizar tarefas básicas como consular um DB para quem não está afim de implementar o MVC e não tem um sistema complexo para desenvolver.
JSP e as JSTL facilitam muito a vida daquele desenvolvedor que tem um projeto pequeno, que o cliente exige que seja desenvolvido em JSP, e não quer aprender servlets, JDBC, MVC, e etc.
Temos que pensar que JAVA é o que é devido também à sua flexibilidade, eu mesmo me apaixonei pela linguagem quando percebi que com ela poderia implementar aplicações desktop, ERP, web, portáteis entre outras…
Gustavo Guilherme BacK
[quote=“urubatan”]você não tem os problemas provindos da JSP, como por exemplo, um outro desenvolvedor detonar com o teu MVC abrindo uma conexão com o banco direto de uma JSP para fazer uma consulta.
[/quote]
Ubiratan,
A JSTL provê TLVs (TagLibrary Validators) que podem ser usados para restringir o que pode ser usado em páginas JSP. Você pode, por exemplo, proibir totalmente o uso de scriplets ou mesmo das tags SQL do JSTL. Na propria série da Java Magazine (segundo artigo, JM8) tem um trecho que fala sobre isso.
Felipe
legal isto, vou dar uma olhada
valeu a dica
Exatamente! A tecnologia JSP vem evoluindo constantemente, e os TLVs fazem parte dessa evolução (embora eles ainda não sejam muito usados, pois a implementação não é tão simples). Aliás, o “salto evolutivo” entre as versões 1.2 e 2.0 será imenso: EL, fragmentos, tags declarativas, configurações usando XML schema, etc…
Para esses times não há solução que dê jeito 
Mas você tocou num ponto válido: não é tão fácil forçar o uso dos TLVs do JSTL. O ideal seria declarar esse tipo de TLV (que valida a página JSP como um todo, e não apenas as tags da taglib) no web.xml. Isso poderia ser sugerido p/ a próxima especificação do JSP (não a 2.0, que já está praticamente encerrada).
Felipe