PORQUE JSP

[pedrotuga 26]

Ainda n trabalhei com JBoss mas posso dizer que o Glassfish é excelente! Simples de usar e configurar, carradas de opções é para mim sem duvida a primeira opção quando se trata de desenvolver aplicações JEE. Quanto ao tomcat n suportar JEE não é verdade até porque Servlets, JSP, JSF etc... faz parte do JEE xD

Pessoalmente acho o glassfish o ideal tanto para web como beans, n gosto muito de tomcat, a meu ver deixa a desejar em algumas coisas.

Ou muito me engano ou não podes carregar o tomcat com EJBs que é basicamente o que o J2EE é. Suportará beans, mas ficaria muito surpreendido se tivesse suporte para EJBs, pelo menos no site da SUN não aparece listado dentro dos outros anteriormente referidos que são oficialmente suportados.

EDIT:

Aqui estão os servidores aplicacionais certificados:

http://java.sun.com/javaee/overview/compatibility.jsp

EDIT2:Fui ver ao manual do jboss, não vem com um container para servlets nem para jsps, usa mesmo o tomcat para esse fim. Calculo que os outros farão o mesmo.

http://docs.jboss.org/jbossas/admindevel326/html/ch9.chapt.html

[falco 31]

Flash não é a melhor das hipóteses, mas se funciona, pronto .. é uma hipótese

Flash... é para quem gosta de excluir invisuais, pessoas que não usam X86 (incluindo iphone e a maior parte dos smartphones).

[IceBrain 1]

Estávamos a falar de soluções para a implementação Drag'n'Drop de ficheiros. Conheces alguma solução que não envolva Flash? Ou Java, porque também não existe JVM para o iPhone.

Ninguém disse que a solução drag'n'drop é a única, quando se implementa uma solução dessas em Flash também se implementaria uma versão com uma caixa de upload comum em HTML para aqueles que não querem/podem usar a outra versão.

[pedrotuga 26]

Está aqui uma valente confusão. 'Drag and drop' significa em português, simplesmente 'arrastar e largar', isso é perfeitamente possível usando javascript e uma qualquer tecnologia no servidor. PHP, java e outras.

Se estás a falar do caso particular de arrastar um ficheiro para dentro da área de um browser, não faço ideia que limitações é que isso implica em termos de implementação, mas isso é apenas um caso muito específico de drag and drop. Para não dizer que se não for para submeter nada para o servidor, qualquer browser com suporte para javascript permite fazer coisas dessas sem qualquer impedimento recorrendo apenas ao javascript ou a outras tecnologias client side.

Tambem não estou a ver qual é a grande vantagem de fazer drag and drop para um browser em vez de utilizar a o UI específico para esse caso que é um painel de escolha de ficheiros.

Mas separando bem as águas. Objectos flash embutidos em páginas web são pequenas aplicações que correm no computador do cliente. JSP e PHP são liguagens de programação que permitem escrever aplcações que usem páginas HTML como interface com o utilidaor comunicando via HTTP, tipicamente sobre a internet, mas não necessariamente.

Dito isto, uma aplicação web escrita em JSP não requer JVM no cliente poir tudo o que este vê é HTML. Nesse aspecto é igual ao PHP.

[yoda 126]

Está aqui uma valente confusão. 'Drag and drop' significa em português, simplesmente 'arrastar e largar', isso é perfeitamente possível usando javascript e uma qualquer tecnologia no servidor. PHP, java e outras.

Se estás a falar do caso particular de arrastar um ficheiro para dentro da área de um browser, não faço ideia que limitações é que isso implica em termos de implementação, mas isso é apenas um caso muito específico de drag and drop.

Sim, mas era desse caso específico que se estava a falar, arrastar ficheiros do desktop para o browser e este fazer upload para o servidor. Isto é concebível com java, javascript não têm permissões para tal, e flash pelo que dizem permite isso.

[IceBrain 1]

O Drag'n'Drop de ficheiros não é um caso particular do que se faz em JS. O drag que se pode fazer em JS é de elementos da DOM, elementos HTML, e é completamente independente da linguagem de servidor, até dá para fazer com páginas estáticas.

Já o Drag'n'Drop de ficheiros é um sistema completamente diferente, que envolve o gestor gráfico do SO, e que a implementação do Firefox faz é apenas abrir um ficheiro que seja largado em cima dele. Quando se corre uma applet Java ou Flash, a zona onde ela é renderizada é uma espécie de janela embutida, que pode receber esses eventos do SO e portanto tratá-los de outra forma.

[magician 2]

Ou muito me engano ou não podes carregar o tomcat com EJBs que é basicamente o que o J2EE é. Suportará beans, mas ficaria muito surpreendido se tivesse suporte para EJBs, pelo menos no site da SUN não aparece listado dentro dos outros anteriormente referidos que são oficialmente suportados.

EDIT:

Aqui estão os servidores aplicacionais certificados:

http://java.sun.com/javaee/overview/compatibility.jsp

EDIT2:Fui ver ao manual do jboss, não vem com um container para servlets nem para jsps, usa mesmo o tomcat para esse fim. Calculo que os outros farão o mesmo.

http://docs.jboss.org/jbossas/admindevel326/html/ch9.chapt.html

Sim tomcat não suporta EJB isso é um dado adquirido! Quanto ao jboss não suportar JSP por acaso não sabia também derivado a nunca o ter usado em relação ao glassfish ele suporta tanto EJB como JSP, sei porque já usei e até tem uma versão embedded para embutir dentro da aplicação.

JavaEE não é apenas EJB é muitos mais que isso, JSP, JDBC, JPA, Servlets e muitas outras coisas fazem parte do JavaEE embora por exemplo muitos pensem que JDBC seja parte do JavaSE. Aqui está a lista dos que está englobado dentro do JavaEE http://java.sun.com/javaee/technologies/javaee6.jsp

[jguilherme 0]

Parece-me a mim que o .jsp permite uma melhor arquitectura, o que implica menos problemas no futuro. Com jsp facilmente dividimos o nosso projecto em camadas fracamente ligadas (logica, apresentação, etc), alem de que podemos seguir uma abordagem orientada aos serviços, muito mais poderosa. Nunca fiz nada de especial com php, mas parece-me que em termos conceptuais pode nao ser a melhor escolha (isto se o programador quiser ir um pouco mais alem do mero ponto de vista funcional).

cumps

[falco 31]

Parece-me a mim que o .jsp permite uma melhor arquitectura, o que implica menos problemas no futuro. Com jsp facilmente dividimos o nosso projecto em camadas fracamente ligadas (logica, apresentação, etc), alem de que podemos seguir uma abordagem orientada aos serviços, muito mais poderosa.

Não é nada que não seja possível com quase qualquer outra solução.

Existem frameworks que permitem isso para quase qualquer outra linguagem... Por exemplo Ruby on Rails, cria essa separação, o Catalyst faz o mesmo para o Perl, Zen framework faz para PHP, Django para Python.  E estes são apenas algumas das frameworks para algumas dessas linguagens...

Nunca fiz nada de especial com php, mas parece-me que em termos conceptuais pode nao ser a melhor escolha (isto se o programador quiser ir um pouco mais alem do mero ponto de vista funcional).

Não entendi onde querias ir com isso. Podes explicar?

[jguilherme 0]

Citar

    Nunca fiz nada de especial com php, mas parece-me que em termos conceptuais pode nao ser a melhor escolha (isto se o programador quiser ir um pouco mais alem do mero ponto de vista funcional).

Não entendi onde querias ir com isso. Podes explicar?

Era um corolario do que disse em cima. Desconhecendo o poder do PHP parecia-me que com JSP podiamos seguir uma arquitectura mais bem definida, com maior abstracção, com maior capacidade de reutilização... Em oposição à abordagem funcional, mais centrada na funcionalidade, e nao no desenvolvimento. Para ter resultados imediatos, se o projecto é pequeno PHP 

Mas realmente nunca fiz grande coisa em PHP. Tenho definitivamente que o explorar mais. Oiço maravilhas em todo o lado, mas tenho dificuldades em acreditar que php seja o mais indicado para grandes projectos. Podiamos fazer um amazon.com ou um sapo.pt em PHP?

[falco 31]

Era um corolario do que disse em cima. Desconhecendo o poder do PHP parecia-me que com JSP podiamos seguir uma arquitectura mais bem definida, com maior abstracção, com maior capacidade de reutilização... Em oposição à abordagem funcional, mais centrada na funcionalidade, e nao no desenvolvimento. Para ter resultados imediatos, se o projecto é pequeno PHP

Isso é mais uma questão de se conhecerem design patterns e de ter disciplina. Embora como já tenha dito em outros posts, é algo que falha na generalidade dos programadores de PHP.

Mas realmente nunca fiz grande coisa em PHP. Tenho definitivamente que o explorar mais. Oiço maravilhas em todo o lado, mas tenho dificuldades em acreditar que php seja o mais indicado para grandes projectos. Podiamos fazer um amazon.com ou um sapo.pt em PHP?

Possível era... Mas eram preciso mais recursos e não seria a ferramenta mais adequada.

Porções do SAPO são feitas com PHP e com outras linguagens, apesar de utilizar bastante Perl (penso ainda ser a linguagem mais usada por lá).

O Amazon é feito em Perl.

Por isso como vez é perfeitamente possível utilizar estas tecnologias para fazer coisas grandes.

[jguilherme 0]

Isso é mais uma questão de se conhecerem design patterns e de ter disciplina. Embora como já tenha dito em outros posts, é algo que falha na generalidade dos programadores de PHP.

É uma linguagem de fácil iniciação. Muitos amadores usam-na. Realmente é o código PHP que vejo que me dá esta má ideia do PHP.

Se eu quiser então desenvolver um Website com um potencial de evolução muito grande, graficamente simples, altamente baseado em serviços, o que tu aconselharias seria Perl?

PHP seriam precisos "mais recursos".

JSP bem... defendes os restantes, mas não vi ainda indicares uma clara desvantagem

ASP terá o problema de ser uma tecnologia registada (necessita programas pagos? servidores mais caros?), usar tecnologia M$, nem sempre muito apoiada pela comunidade.

Existe ainda a framework Ruby on Rails que referiste, sobre a qual já ouvi dizer ser muito poderosa, e de grande abstracção.

[falco 31]

Se eu quiser então desenvolver um Website com um potencial de evolução muito grande, graficamente simples, altamente baseado em serviços, o que tu aconselharias seria Perl?

O ser graficamente simples não tem nada a ver com isto.

Posso recomendar Perl pelo menos para um site que precise de escalar muito e/ou se quiseres ter controlo do servidor Apache a um nível que PHP e algumas outras alternativas não permitem. Claro que não digo que é a solução ideal para todos os casos, mas pelo menos para este tipo de casos era muito provável que eu o pusesse em cima da mesa para analisar se era a solução para a situação em particular.

JSP bem... defendes os restantes, mas não vi ainda indicares uma clara desvantagem

Desvantagem de quê?

Dos outros em relação ao JSP?

Não conheço muito o JSP, por isso não digo muito sobre ele. Também não sou contra a utilização de JSP, acho que é uma solução válida para muita coisa.

ASP terá o problema de ser uma tecnologia registada

Há pelo menos uma implementação livre de asp.net, que também pode ser obtida gratuitamente. Mas não sei o quanto é tecnicamente fiável, para além de como não fazer parte dos standards relacionados com o .net, tem questões relacionadas com patentes que podem vir a tornar-se problemas graves. E sim a implementação de que falo é a do mono, que corre nativamente em vários OS incluindo GNU/Linux. Tem ainda o problema de teres que dominar outras tecnologias, etc...

Existe ainda a framework Ruby on Rails que referiste, sobre a qual já ouvi dizer ser muito poderosa, e de grande abstracção.

Tal como as outras que mencionei. O RoR (Ruby on Rails) segue o padrão de design MVC, e o Catalyst, o Django, também e até mesmo a Zen Framework pode ser utilizada para MVC.