aspose file tools*
The moose likes JSF and the fly likes different method name Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "different method name" Watch "different method name" New topic
Author

different method name

fabio fabios
Greenhorn

Joined: Jun 13, 2011
Posts: 4
Is possible to invoche a method name foo() in backing bean form a JSF commandButton tag in parameter rendered, without being obliged to rename it in the backing bean isFoo();?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16145
    
  21

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

rendered="#{myBean.foo}"

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.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: different method name