t:inputText id="test", how to get its value?

[peter tong]

in a selection criteria screen, there is a <t:inputText id="test"/> component, how to get its value?

[Himanshu Gupta]

Peter getting the value of the specified component is easy. Make use of the value attribute. Are you comfortable with the concept of backing bean ? If yes then it will come to you in a minute.

I will try to give a small example for you here.

In the page the code will be

<t:inputText value="#{beabName.propertyName}" /> 

In backing Bean make a property and write its getter and setters as well.


Hope this will solve your problem.

[Tim Holloway]

You don't "get" a JSF value. A JSF page is a View, and it references a Model. Your tag misses a critical attribute:

<t:inputText id="test" value="#{bean.property}"/>

This will cause the JSF Controller to inject the value of the inputText field into the property named "property" of the bean which has been named "bean" in your jsf faces-config.xml file.

[peter tong]

Oh, theat means all h:inputText must have a backing bean,otherwise we have no method to get the value?

[Himanshu Gupta]

JSF is a framework and backing bean is a part of it. You cannot test the functionality of most of the componenet without using backing bean. Please go through some good examples to understand it in a better way.

[Tim Holloway]

 

Originally posted by peter tong:
Oh, theat means all h:inputText must have a backing bean,otherwise we have no method to get the value?

Before you get into details, you really need to get an understanding of what JSF is all about. I think, actually, that you're looking at it as though the JSF pages are where the program logic is based, and that isn't so. In fact, one of the bits of advice I provide more than almost any other in this forum is that JSF pages should have as little logic on them as possible. None at all, if you can.

JSF is about as complete an implementation of the classic Model/View/Controller paradigm as you can manage when HTTP is your underlying transport mechanism. It's also very much based on the concept of Inversion of Control (IoC), where you don't "get" things, they're injected into your code.

I had to learn to think of web application structure a lot differently when I started working with JSF. So will you.

[Kevin P Smith]

Just been looking at JSF quickly and have a quick question to ask. I've put it here because this thread seems to be along the same lines...

I found this quick sample 2 page app called JSFKickStart.

Basically has 2 JSPs and a Bean, with the following smippets

JSP1 - <h:inputText value="#{personBean.personName}" required="true" />
JSP2 - <h:outputText value="#{personBean.personName}" />
Bean -
public class PersonBean {
String personName;
public String getPersonName() {
return personName;
}
public void setPersonName(String name) {
personName = name;
}
}

Now my question is, how does JSP1 or JSP2 know to use the Getter or Setter?

Usually you'd expect to see something like

JSP1 - <h:inputText value="#{personBean.setPersonName}" required="true" />
JSP2 - <h:outputText value="#{personBean.getPersonName}" />

But as if by magic JSF seems to know which to use, what's the 'background' logic going on here?

PS: Early opinion is that JSF look very much the thing for me, but it will be very hard to drag me away from 5 years or so of classic JSP/Servlet/Bean coding!

---

Just like to add another observation to this question...

Pu a couple of simple Sys.outs in the Bean to see when, what is called and noticed this:

[#|2008-11-20T17:43:36.889+0000|INFO|sun-appserver-pe9.0|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpWorkerThread-80-0;|
getPersonName -- JSF just called this!|#]
[#|2008-11-20T17:43:36.889+0000|INFO|sun-appserver-pe9.0|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpWorkerThread-80-0;|
setPersonName -- JSF just called this!|#]
[#|2008-11-20T17:43:36.899+0000|INFO|sun-appserver-pe9.0|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpWorkerThread-80-0;|
getPersonName -- JSF just called this!|#]

It 'gets' the method getPersonName twice!
It gets the method getPersonName, then gets the method setPersonName, then gets the method getPersonName again!

That seems an extra 'call', why is this?
[ November 20, 2008: Message edited by: Keith Seller ]