JSF Basico

Sim… porém… até onde eu sei, vc não teria a mesma performance…

por exemplo:

vc pode colocar um input como exemplo

<input type="text" name="noPessoa" />

e na action vc recupere essa resposta usando um request.getParameter("noPessoa");

ou seja, você pode até tentar não usar as tags… mas começa a não ter sentido vc usar um framework desses sem usar as taglibs que eles tem suporte.

Essa solução de pegar os valores do request eu não sei se seria muito válida não, pois pode gerar vários problemas e se vc for usar isso, não justifica muito usar jsf, use struts ou servlet no caso. Caso vc queira usar os componentes do html para agilizar algum trabalho de webdesigner, vc pode dar uma olhada no facelets e o atributo jsfc.

Segue abaixo o trecho do site: http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=5332

[i]
O Atributo jsfc

O Facelets permite, através da tag jsfc, incluir trechos de código JSF nas tags HTML, ganhando com isso, a funcionalidade de podermos utilizar uma ferramenta para edição gráfica das páginas, podendo assim, a página ser construída por um designer e só depois o programador colocaria os atributos necessários dentro do HTML.
[/i]

<form jsfc=?h:form?>

      Login: <input type=?text? jsfc=?h:inputText? value=?#{bean.user}?/>

      Senha: <input type=?password? jsfc=?h:inputPassword? value=?#{bean.password}?/>

<input type="submit" jsfc="h:commandButton" action="#{beam.login}" value="Submit" />

</form>

[]'s

Não… vc não pode utilizar

<input type="text">

Em JSF…

Se estiver fazendo assim, você não está utilizando JSF…

Lembrando que JSF, vc não tem o controller (ou action)… então… isso aqui:

request.getParameter("noPessoa");

Pode considerar que é inexistente no JSF (tem até como fazer, mas vc nao terá controle nenhum sobre isso, e vai contra o JSF)

Se você acha que você está precisando de:

<input type="text" name="noPessoa" />

Ou acha que isso é mais simples… e mais natural (como eu também penso)

Considere não utilizar o JSF…

Valeu Galera! , vou ter que estudar outra forma … começarei estudar o Struts 2… acho que com ele conseguirei utilizar o HTML.

Filosófico…

Galera adooooora… hehehehe…

Primeiro…

Com facelets é possível usar o “jsfc”, onde vc diria qual o componente jsf vc está querendo usar em cada caso. Como disse o Bruno ali…
Mas,
Se está aprendendo JSF… aprenda JSF… Tem um tutorial bom aqui no GUJ.
As tags são bem intuitivas. Rapidinho vc pega o jeito.

Segundo…
JSF tem controle SIM SENHOR…

Controle = ManagedBean + NavigationRule;

Mas não é um controle igual uma Action do Struts por exemplo…

Não é um Front Controller…

Ham ???

:shock:

o que ???

A propósito…
Bela logomarca, cara.

proteus_adi:

Ham ???

:shock:

o que ???

Um Front Controller, é um controller onde o request chega primeiro nele…

Ele é que recebe o request…

proteus_adi:

A propósito…
Bela logomarca, cara.

Valew…

rodrigodsw2005:

Valeu Galera! , vou ter que estudar outra forma … começarei estudar o Struts 2… acho que com ele conseguirei utilizar o HTML.

Indicaria o Spring MVC, ou o VRaptor…

O VRaptor e o Spring MVC são praticamente a mesma coisa… só que o VRaptor é mais fácil de configurar e fazer um quick start…

O Spring MVC tem algumas tags que podem te ajudar… são tags bem simples…

Prezado,

Model-View-Controller (MVC)

The MVC pattern’s purpose is to decouple Model (or data) from the presentation of the data (View). If your application has more than one presentation, you can can replace only the view layer and reuse code for the controller and model. Similarly, if you need to change a model, the view layer remains largely unaffected. Controller handles user actions that might result in changes in the model and updates to the views. When a user requests a JSF page, the request goes to FacesServlet. FacesServlet is the front controller servlet used in JSF. Like many other Web application frameworks, JSF uses the MVC pattern to decouple the view and the model. To handle user requests centrally, the controller servlet makes changes to the model and navigates users to views.

bruno.leite:

Prezado,

Model-View-Controller (MVC)

The MVC pattern’s purpose is to decouple Model (or data) from the presentation of the data (View). If your application has more than one presentation, you can can replace only the view layer and reuse code for the controller and model. Similarly, if you need to change a model, the view layer remains largely unaffected. Controller handles user actions that might result in changes in the model and updates to the views. When a user requests a JSF page, the request goes to FacesServlet. FacesServlet is the front controller servlet used in JSF. Like many other Web application frameworks, JSF uses the MVC pattern to decouple the view and the model. To handle user requests centrally, the controller servlet makes changes to the model and navigates users to views.

Certo prezado… mas esse FacesServlet, não é voce que escreve… (como a Action do Struts)

Talvez eu esteja me confundindo aqui… acho que o termo correto é ApplicationController… para esse Controller que recebe o request e você determina o que será feito…
Esse ApplicationController… vc não tem no JSF…

Mas independente do nome desse controller… o fato é: no JSF você não tem um controller que recebe o request…

rogelgarcia:

proteus_adi:

Ham ???

:shock:

o que ???

Um Front Controller, é um controller onde o request chega primeiro nele…

Ele é que recebe o request…

http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
http://java.sun.com/blueprints/patterns/MVC.html

Front Controller is a Presentation Pattern.
“The controller provides a centralized entry point that controls and managers Web request handling. By centralizing decision points and controls, the controller also helps reduce the amount of Java code, called scriptlets, embedded in the JavaServer Pages (JSP) page.” blá blá blá.

MVC is a Pattern… everything is a pattern… oh my good… :S
That purpose is separe view and model [data model, business model, all model] using a controller as connector…
A fusebox coldfusion is a control, a managed bean is a control and a navigation rule is a flow control… every code writed to control some interaction between view and model is a control…

Save the google translator…

rsrs**
Agora… Spring MVC? Não… :S, VRaptor? tbm não…
Num faz isso com o menino…

Deixa o cara usar JSF…

VIVA O JSF

A propósito…
Bruno, sua logo não é legal.

hahaha

Hehehehehe

Acho q o termo correto para o controller que queria me referir é ApplicationController… é que os dois podem se confundir… dependendo do ponto de vista

O cara é que decide o que ele quer usar …

Mas pq não Spring MVC?? Ou então, pq JSF??

JSF sozinho, ou com JBoss Seam?

JSF sozinho é razoavel.
JSF + Facetets é bom.
JSF + Facelets + Spring pra Inject e Bussiness OU Ejb3x… Ótimo.

Combinação q, claro, junto com um bom café, implementam uma base bacana pra sistemas bons e não engessados.

Diga “não” aos Frameworks Intrusivos e complicados que não são “padrão de mercado”…

Eu não entendo porque o Spring MVC num pegou por aqui.
Acho o JSF complicado demais pra fazer uma aplicação.

proteus_adi:

Diga “não” aos Frameworks Intrusivos e complicados que não são “padrão de mercado”…

Então… devemos seguir a filosofia: Aonde a vaca vai o boi vai atrás

??

:lol:

javamaniaco:

Eu não entendo porque o Spring MVC num pegou por aqui.
Acho o JSF complicado demais pra fazer uma aplicação.

Mas a maioria das empresas usam outras tecnologias, diferentes de JSF…

Hahaha…
Tem senso de humor.

Na verdade devemos seguir a filosofia: “Em time que está ganhando… não se mexe”.

Frameworks de mercado tem as seguintes vantagens:

1. Ficam mais bonitas no currículo [ no caso do desenvolvedor ].
2. Possui mais profissionais qualificados no mercado [ no caso das empresas ].
3. Seguem padrão arquitetural mais a risca.
4. São normalmente pouco intrusivos: Baixo acomplamento.
5. São normalmente melhor testados: Baixa densidade de erros arquiteturais.
6. Possuem melhor referência: Melhor documentação e rastreamento de falhas conhecidas.
7. Possuem melhor difussão de conhecimento: Se você não sabe fazer… há alguem no GUJ que sabe.

JSF é a aposta “padrão” da Sun.
A versão 2 agora já incorpora alguns recursos que são vantagens em outros frameworks, como o jsfc do tapestry ou annotations beans do Spring.

Não é inteligente REINVENTAR a roda.
É melhor usar a roda que alguem inventou e que um monte de gente já testou…
inventar o CARRO e ficar rico…

hahaha

Agora…
Do Seam… bom… há quem goste. Mas, ele é muito intrusivo.
Ou vc constroi a aplicação para Seam, ou não…

Mas o Spring MVC, também é padrão de mercado… e possui todas essas qualidades que voce citou…

Então… tanto faz se usar Spring MVC ou JSF

!!?!

Mas antes disso tudo, não seria interessante o framework ser bom, em primeiro lugar?

Pq o mercado todo, poderia estar usando um lixão, e todo mundo seguir, só porque é padrão?! (Só uma hipótese, não to falando que o mercado usa um lixão hehe)

Então é melhor o framework ser BOM? ou ser de MERCADO?

Qual é o objetivo de utilizar um framework?

O objetivo de utilizar um framework é “não reinventar a roda”.
Abstrair problemas estruturais e ter tempo e espaço para focalizar no objetivo real: O produto; O negócio;

E,
Pq SpringMVC?
Cara… Spring MVC é muito bom. Sou fanzasso de Spring… Mas para Injeção de dependencia. Bom pra camada de negócios.
Mas, até mesmo essa parte do framework está sendo substituída pelo EJB3x, que, faz tudo [ou quase] que o Spring, só que mais “padronizado” [afinal, é especificação da Sun].
SpringMVC é um framework bonitinho pra construir aplicações MVC. Arquiteturalmente “limpo”. Mas,
Eu não apostaria em SpringMVC. Já é tecnologia do passado. Já foi o tempo.

“O quente do verão”, como dizem aqui, é mesmo o JSF…

Faz uma pesquisa por vagas de emprego e compara mercado para SpringMVC e pra JSF…

Eh…
Acho q vai chover.
Tá mto calor…

Bem, eu acho que o objetivo de um framework primariamente, é fazer a aplicação mais rapidamente.
Se vc tem um framework, onde vc nao tem que reinventar a roda, mas dá tanto problema que fazer na mão é mais rápido, considero ser melhor fazer na mão.

Sobre o Spring estar sendo substituido pelo EJB 3, isso num é valido não… O pessoal do EJB está cada vez mais copiando o Spring, mas isso não quer dizer que o Spring será substituido…
Essa copia só mostra que o pessoal do JCP é atrasado e não tem visão das coisas, afinal, a quantos anos existe o Spring? E o Spring surgiu exatamente como uma alternativa ao EJB. Que era trabalhoso e burocrático.

Spring MVC não é tecnologia do passado hehehehe…

Acontece que existem basicamente dois tipos de camada de visão, Action Based e Component Based…

Component Based é o JSF, e Action Based são os outros tipo Spring MVC… Mas não quer dizer que component based vai substituir o action based…

Na minha opinião, eu acho que inclusive component based é uma abstração que não funciona para web…

Eu nunca errei numa aposta não …

Vou apostar nos action based…

Tão tá bom, né?!

o kra, quer vir ralar aki na empresa naum? tá precisando de gente q nunca erra…

Manda os números da mega sena tb =)

Não falei que nunca erro… falei que nunca errei numa aposta de o que vai sumir e o que vai ficar

Digo que o Spring vai ficar!

E os Action Based tb…

Mas me dá o endereço aí que vou na sua empresa… sem problemas :lol:

bruno.leite:

o kra, quer vir ralar aki na empresa naum? tá precisando de gente q nunca erra…

Manda os números da mega sena tb =)

Me manda o que está precisando que eu cobro a consultoria

proteus_adi:

O objetivo de utilizar um framework é “não reinventar a roda”.
Abstrair problemas estruturais e ter tempo e espaço para focalizar no objetivo real: O produto; O negócio;

E,
Pq SpringMVC?
Cara… Spring MVC é muito bom. Sou fanzasso de Spring… Mas para Injeção de dependencia. Bom pra camada de negócios.
Mas, até mesmo essa parte do framework está sendo substituída pelo EJB3x, que, faz tudo [ou quase] que o Spring, só que mais “padronizado” [afinal, é especificação da Sun].
SpringMVC é um framework bonitinho pra construir aplicações MVC. Arquiteturalmente “limpo”. Mas,
Eu não apostaria em SpringMVC. Já é tecnologia do passado. Já foi o tempo.

“O quente do verão”, como dizem aqui, é mesmo o JSF…

Faz uma pesquisa por vagas de emprego e compara mercado para SpringMVC e pra JSF…

Não acho que o Spring ficou pra traz… muito pelo contrário… vejo ele crescendo no mercado cada vez mais… principalmente porque o seu suporte vem melhorado performance…

ralphsilver:

bruno.leite:

o kra, quer vir ralar aki na empresa naum? tá precisando de gente q nunca erra…

Manda os números da mega sena tb =)

Me manda o que está precisando que eu cobro a consultoria

números da mega sena, mas tem q cumprir o requisito: ‘nunca errar’, pagamento pós realização do projeto.

Os numeros da MegaSena rola, hem?!

Agora…
Ralar aqui num vai dar não…
Aquele desculpa básica de RH: SuperQualificação…]
:twisted: :twisted: :twisted: :twisted:

Mas, HEEEEM?
E o JSF q era o assunto mesmo?

Acho q o cara q criou o post nem entra mais…
Hahaha

Cara…
Pessoal aqui da empresa é bem uniforme nessa opinião.
Principalmente pessoal da Arquitetura…

eu mesmo semana passada levei uma sapatada nisso ai…
Citando a facilidade de testar uma aplicação Spring… e levei um “Microcontainer EJB + JUnit” na cara…

Spring é bom. Pra NEGÓCIO e Injeção. MAS, o EJB já tem muita coisa que ele tem de vantagem. Ou seja, já não é vantagem. É mais um.
mas, gosto dele. Uso inclusive quando posso.

Agora…
Spring MVC… não é bom. não tem vantagem… e não tem mercado.

Mas o que qui o pessoal da arquitetura alegou sobre o Microcontainer EJB + JUnit??

Sobre a utilização de EJBs? Vocês aí precisam de EJBs?? Um POJO não resolveria??

Qual seria uma alternativa Action Based que tem mercado, em oposição ao Spring MVC?