1. Because a View Template isn't supposed to be software, it's supposed to be data. And, more importantly, the "value=" attribute isn't a function call, it's a
property reference.
Consider this:
See the difference?
The original
JSP spec had an expression language (EL) that permitted certain types of read-only substitution using expressions like "${value}". JSF, however, needs true references (read AND write), so they came up with a "reference" notation, which is "#{value}"
Yes, you can code an expression call
in this particular case, but it's a special case. Besides, it pollutes the Separation of Concerns concept by putting server-oriented logic in the View. It's also more typing to do "getXXX()" than to simply reference "xxx", for those of us who are lazy.
2. JSF uses POJOs wherever it can. But action methods weren't designed to take arguments, so there had to be some way of determining which row in a table the client had selected for the action when you had a command button or link in the table clicked on. To allow the underlying data to remain POJO, the DataModel wraps it with the necessary context information. So that the action method can tell which row was selected by invoking the DataModel's getRowData() method (or rowIndex, if you prefer). A plain list or array wouldn't have a "getRowData()" method.
It's true that by crude brute force you can forcibly parameterize your View definition to do the same thing without a DataModel as of JSF2, but that's what it is. Crude brute force attempts to make JSF look like "The Way We've Always Done It" instead of leveraging JSF's power to simplify this common task. And JSF is still going to build a DataModel, regardless, but you won't have access to it, so it's at least as much work on the server's part and less power available to the developer when using force.
3. It depends on what you are doing and how you get there. A lot of times I have a CRUD backing bean, which, due to quirks in how JSF is put together may also be responsible for a table view of the object in question.
Most often, I'll be navigating from somewhere else, and in the backing bean of the original page, one of the injected (Managed) properties will be the bean that handles this table and its CRUD functions. As an example, let's say we have a Person edit page and we want to edit that person's Address (which is a 1-to-1 relationship for this example).
In the Person edit page, there will be an "Edit Address" button that invokes the "personBean.doEditAddress" method:
JSFUtils is just a class I made up to hold common JSF functions so that they wouldn't litter my backing beans with a lot of JSF-specific details. Returning "null" means that the current page is re-displayed instead of the "Edit Address" page.
Over in the AddressBean class, the "beginEdit(int addressId)" method is where I ask the database to fetch the address record with ID "addressId" and set the addressBean.address property to the returned Hibernate object instance so that it could then edit the details. If that record cannot be found, this method returns "false".
I almost never do any database work in the constructor, since the actual persistence methods are usually injected and therefore their "set" methods haven't been invoked yet. A @PostConstruct method has the persistence objects injected, but it's generic and only invoked the first time after the bean is constructed. Good enough, perhaps for View scope, but not if addressBean was session scoped, as it would have to be in order to get injected into personBean.
So the general-purpose method beginEdit(int addressId) allows me to re-use this bean over and over. It often will invoke a method named init() that clears any local variables (and is also often invoked by the constructor). A beginAdd() method is similar, except that instead of fetching a Hibernate object, it constructs a new, empty one and sets a flag that tells the "doSave" method I create for my "Save" button to do an "add" instead of an "update".
