2
votes

I am reading Core JavaServer Faces 3rd edition and I got a question about the encoding and decoding of JSF pages.

When the page is about to be rendered it will first go through the XHTML page containing JSF tags. Each JSF tag has a own tag handler class and they co-operate to make the component tree of that page. All other tags is ignored.

Each component has a own renderer that knows how to generate the HTML. Now the book says:

(This is a h:inputText tag)

Each component has a renderer that produces HTML output, reflecting the component state. The renderer of the UIInput object asks the JSF implementation to look up the unique ID and the current value fo the expression user.name.

The question is:

Why does the book say that the implementation asks for the current value of the expression user.name? I would expect that the implementation instead asked the component - in this case UIInput - which had some reference to this user bean instead? Because, doesn't that class "reflects" the JSF tag in code?

I probably have misunderstood the concept and I would like to learn it.

3

3 Answers

4
votes

To get the output value of an EditableValueHolder like UIInput, a Renderer would typically call getValue(). This will generally return:

  1. The value from getSubmittedValue() if input validation or conversion failed
  2. The object set explicitly by calling setValue(Object) if any
  3. The result of the value ValueExpression if any

The component defines behaviour. Ideally, it should be loosely coupled to the renderers, markup and data sources. The component doesn't care what its data source is - it doesn't have to be a managed bean. Getting and setting values is the responsibility of the ValueExpression.

What the ValueExpression evaluates to depends on the context.

0
votes

Parameters passed to JSF components are basically EL (expression language) expressions, and evaluating those can be a lot more complex than accessing some reference - The JSF EL is a programming language of its own, with syntax and semantics only indirectly related to Java.

0
votes

I would expect that the implementation instead asked the component ?

In my opinion, UIInput components and bean's properties are 2 distinctive things. They do not have any relationships with each other until we bind the value attribute of the UIInput component to a property of the bean.

In other words, UIInput components by themselves do not have anythings so called current values. They are simply a value displayer & getter. So, the renderer will have to ask the JSF implementation (which is usually the ManagedBean), for the value that the UIInput components should display.

... UIInput - which had some reference to this user bean instead

In general, the relationship between UIInput, a property and JSF implementation (ManagedBean) should look like this: UIInput - ManagedBean - bean properties. The renderer needs to communicate with the man in the middle (ManagedBean) to get what it wants because UIInput does not have a direct relationship with bean's properties.

The above are my current understanding. Please correct me if I'm wrong! :)