That kind of stuff is a violation of the basic purpose behind MVC, which is that the View should do no logic. A JSF View is, first and foremost a mapping of model data values against display element definitions, secondly a mapping of backing bean action handlers to action display elements.
When you make part of a View conditional based on the model state (using the "rendered") attribute, the reason that the model property for, say
has to be:
public boolean isFoo()
is that backing beans are POJOs, and the basic Java definition of a POJO is that properties are accessed via mutator methods with a specific naming convention. To set a property, its "setXxx()" method is called. To get a non-boolean, its "getXxx()" method is used. For Booleans, the name should be "isXxx()".
This isn't just an arbitrary rule. One of the primary functions of JSF is that it should be capable of doing as much of the "grunt work" as possible. By making the backing beans be POJOs with POJO-standard mutator methods, the JSF Controller knows exactly how to fetch and update View data without making you code that functionality explicitly.
In some cases, you may not have the option to add an "isFoo()" method to a backing bean. If this is due to some sort of Management edict, all I can do it pity you. And recommend keeping the CV up to date, since places that are that controlling aren't generally healthy work environments. On the other hand, if you're trying to use a persistence Model object as a backing bean, think again. That doesn't work very well. Use a façade, decorator, or container object and you'll find life a whole lot easier. Similarly, if you're using a canned business object, consider buffering it through a separate backing bean.
Backing Beans were never intended to merely glue the View directly to the Business Logic and Persistence objects. Sometimes, in some simple cases you can do so, but for heavy duty apps, they should be just another tier in the overall architecture.
An IDE is no substitute for an Intelligent Developer.