Qual é a necessidade do JSF, quando a IU pode ser alcançada com bibliotecas JavaScript como jQuery e AngularJS

Eu estava lendo sobre o JSF que é uma estrutura de IU e fornece alguns componentes de IU. Mas como é melhor ou diferente do número de componentes que estão disponíveis em jQueryUI, AngularJS, ExtJS ou mesmo em HTML, CSS e JavaScript simples.

Por que alguém deveria aprender JSF?

JSF para JSP / Servlet / HTML / CSS / JS simples é como jQuery para JS simples: faça mais com menos código. Para usar PrimeFaces ( baseado em jQuery + jQuery UI) como um exemplo, navegue por seu mostruário para ver exemplos de código completos. BootsFaces ( baseado em jQuery + Bootstrap UI) também tem uma vitrine com exemplos de código completos. Se você estudar esses exemplos de perto, verá que basicamente precisa de uma classe Javabean simples como modelo e um arquivo XHTML como visualização.

Observe que você não deve ver o JSF como uma substituição de HTML / CSS / JS sozinho, você também deve levar em consideração a parte do lado do servidor (especificamente: JSP / Servlet). O JSF elimina a necessidade de todo o clichê de reunir parâmetros de solicitação HTTP, convertendo / validando-os, atualizando os valores do modelo, executando o método Java correto para fazer o negócio e gerando o código clichê HTML / CSS / JS. Com JSF você basicamente acaba com uma página XHTML como definição de visão e uma classe Javabean como definição de modelo. Isso acelera muito o desenvolvimento.

Como acontece com todo framework MVC da web baseado em componente, você tem no JSF um controle menos refinado sobre o HTML / CSS / JS renderizado. Adicionar código JS personalizado não é tão fácil, já que você tem que levar em consideração o estado de exibição JSF no lado do servidor (por exemplo, habilitar um botão desabilitado no lado JS não habilitará o botão no lado JSF, que por sua vez é um grande vantagem de segurança). Se isso é, no entanto, um grande obstáculo, então procure uma estrutura MVC da web baseada em ação como Spring MVC . Você apenas levará em consideração que deve escrever todo o código HTML / CSS / JS (e prevenção contra manipulação de XSS, CSRF e DOM!) Por conta própria . Além disso, se você voltar do Facelets para o JSP, também perderá os recursos avançados de modelagem.

Por outro lado, se você tiver um grande site baseado em JSP / Servlet / HTML / CSS / JS / jQuery e quiser refatorar o código repetido JSP / Servlet / HTML / CSS / JS / jQuery em componentes reutilizáveis, uma das soluções seria o JSF. Modelos personalizados, tagfiles e componentes podem ajudar nisso. Nessa perspectiva, JSF está acima de JSP / Servlet / HTML / CSS / JS / jQuery (e é também por isso que é muito importante entender esses fundamentos antes de mergulhar em JSF).

Você pode encontrar um projeto baseado em JSF inicial do mundo real aqui: Aplicativo Java EE Kickoff . Você verá que ele contém ao lado de JSF como bons HTML5 , CSS3 e jQuery .

Veja também:

• Diferença entre Request MVC e Component MVC
• Diferença entre JSP, Servlet e JSF
• Quais são as principais desvantagens do JSF 2.0?
• É possível usar JSF + Facelets com HTML 4/5?
• Quando usar <ui: include>, arquivos de tag, componentes compostos e / ou componentes personalizados?

O JSF foi criado para que as lojas de java não precisassem aprender coisas como jQuery e construir JS complexos, mas focar em uma pilha puramente Java. Em um mundo onde tempo é dinheiro e muitos lugares já focados no desenvolvimento Java, uma linguagem / peça a menos na pilha torna o treinamento e a manutenção mais rápidos e, portanto, mais baratos.

Acrescentarei que JavaScript é fácil de se tornar um pesadelo de manutenção em grandes equipes, especialmente se alguns dos desenvolvedores do projeto não são muito experientes na web.

Com Javascript e estruturas como jQuery, você tem total flexibilidade e controle total. Com ext's etc você perde muito controle e deve se adaptar ao framework. Com o JSF você perde totalmente o controle e deve se adaptar totalmente ao framework. Você é chamado em ciclos de vida etc. e, finalmente, você não tem controle quando a chamada para o servidor pode ser feita e onde não pode. Se você vai fazer algo considerado 'especial', você está em uma posição muito difícil. E no mundo JSF, mesmo coisas básicas como classificação de tabelas com várias colunas ou campos onde você pode digitar apenas um conjunto limitado de caracteres (como campo de número) são consideradas 'especiais'.

No entanto, quanto mais flexibilidade você tiver, mais erros ou práticas inadequadas poderá cometer. A alta flexibilidade funciona apenas com programadores altamente inteligentes; outros transformarão o projeto em um pesadelo incontrolável.

Mas, com JSF e sua flexibilidade limitada, sempre há apenas algumas (ou mesmo apenas uma) maneira correta de fazer algo. Você é muito limitado, não pode fazer atalhos, deve escrever mais XML etc. - mas ao se adaptar ao padrão, há melhor controle sobre o código que os programadores inexperientes ou pouco qualificados irão produzir. Como resultado, as grandes corporações amam o JSF porque é "mais seguro" para elas.

Quando mudei do GWT para o JSF, fiquei chocado com quantas coisas, que eram naturais para mim, eram consideradas altamente atípicas e com quantas coisas simples eram tão difíceis de conseguir. Além do mais, até mesmo fazer as menores alterações, como adicionar ':' sinal após rótulo, que no aplicativo GWT / jQuery desenvolvido estaria alterando um rótulo de geração de função, exigia a alteração de dezenas de arquivos com propriedades localizadas, o que nem mesmo foi considerado por qualquer um exceto eu estranho ...

Os benefícios de usar JSF não estão apenas em gerar xhtml + css + js. Às vezes, o JSF impõe uma restrição à marcação que você pode gerar, como qualquer estrutura baseada em componente. Mas o JSF não serve apenas para isso, seu estilo de vida ajuda muito. Depois de validar a entrada, ele pode atualizar o modelo e sincronizar seus beans do lado do servidor sem nenhum esforço. você apenas diz "o que quer que o usuário digite aqui, verifique se é um número, se sim então armazene na propriedade YY no objeto XX" e o JSF fará tudo isso.

Então, sim, você ainda pode usar JQuery, JS, etc. Mas JSF oferece muitos benefícios quando se trata de escrever código do lado do servidor e evita muitos problemas.

Eu discordo veementemente que jsf acrescente algo. Isso apenas adiciona sobrecarga. Fazer coisas de interface do usuário no servidor é a coisa mais ridícula que eu já ouvi. E o javascript em grandes equipes funciona muito bem - é chamado de reutilização de código.

Apenas envolva o jquery em algumas tags jsp, isso é tudo que você precisa e está feito, e não suporte os .hackles e problemas de escalabilidade com.jsf e richfaces.

Tendo trabalhado com JSF, Spring MVC, Struts, Grails, JQuery e ExtJS, minha opinião é que Grails + ExtJS é uma combinação poderosa.

Eu escolheria Grails em vez de JSF qualquer dia. Eu gosto da integridade do ExtJS como a biblioteca e estrutura do lado do cliente, mas ele vem com uma curva de aprendizado mais íngreme do que JQuery.

Aqui estão as maiores diferenças entre jQuery e JSF:

• sem arquitetura MVC
• sem controle de estado (data de armazenamento na sessão ou conversa, limpeza automática, etc.)
• não (padrão) biblioteca de validação
• nenhuma biblioteca de modelos
• sem navegação / roteamento avançado
• lado do cliente

jQuery nunca foi planejado para ser usado como um webframework full stack. Era mais voltado para substituir o código JS de baixo nível para que escrever JS se tornasse mais fácil e mais poderoso em menos linhas de código.

E, portanto, deve ser usado principalmente para adicionar comportamento em elementos HTML.

Tendo usado a estrutura ExtJS para um grande aplicativo da web, sei como é fácil de usar. O ExtJS (Schena) é mais adequado para interações de banco de dados (Oracle 11g) na arquitetura MVC. A Visualização era para as interações visuais / do usuário. O controlador especificou o 'processamento' e os gatilhos que precisavam ser usados ​​nos pacotes PLSQL (a API para o CRUD, consultas de seleção SQL etc.). O modelo e os arquivos de armazenamento foram usados ​​para 'mapear' os itens de dados para o Viewer / entradas.

ExtJS não é adequado para interfaces da web sem uso intensivo de banco de dados - onde Angular JS pode ser uma opção melhor.