There is a time and a place for mucking around using lots of javax.faces classes and running amok inside the JSF component tree, but it's vary very rare, even for hard-code nerds like me.
Unfortunately, far too many people use this kind of stuff gratuitously, and I've never been able to determine whether it's because they can't believe the standard features could be as simple as they are, because they got hold of outdated JSF documentation (the Internet is bad for this), or if they're just trying to show how clever they are (which they aren't if they do this kind of stuff just for the heck of it).
Having made that observation, I'll assume that the article in question had a real need to do things the hard way (which may or may not be true) and attempt to explain what's going on.
In the JSF that most of us should be using most of the time, you bind a View Definition to a backing bean property using a simple EL expression and the JSF "value" attribute. Like so:
The backing bean, of course, has simple POJO get/set accessor methods and JSF invokes them to update the Model (backing bean) from the View and vice versa.
Sometimes - although as I said, rarely - there's a need for a less straightforward approach. For the record, I think that in all the years I've used JSF, I have exactly one and only one application that needs to do this.
In that case, you end up manually replicating the JSF standard functionality (more or less). In a method that accesses the JSF component tree directly, such as a Listener, you cannot simply yank the View value (or conversely set that value) by using the get/setValue methods of the component, because that's not where the actual value itself is held.
What is in the component's "value" property is the EL that would have otherwise been coded on the View Definition "value=" attribute specification. So to get/set the actual object value, you have to manually set up and invoke the EL processor.
First, your have to obtain the EL Context from the FacesContext. The EL Context defines how EL works. It's where the various expression resolvers get connected together. For example, in a typical Spring-assisted JSF webapp, my EL resolver can ask both JSF itself and the Spring bean factory for named objects, and this is where their respective interfaces plug in.
The you have to invoke the ELResolver to evaluate the EL expression that came back. The ELResolver not only looks up named objects in the ELContext, it also interprets any EL logic expressions. As you can see, in the example code, the ELResolver itself is also stored in the ELContext. And yes, it would be cleaner (and often more efficient) to code it this way:
For easier debugging, I'd typically also break out the ELResolver into a named variable, but the execution wouldn't care.
Customer surveys are for companies who didn't pay proper attention to begin with.