Backing beans are not Controllers. They are Models.
I'll be glad to discuss nuances, but I've seen what kind of horrors people code when they don't observe the distinction. Hence, the not-so-subtle hint.
Bundles are typically attached to JSF webapps in faces-config.xml file. A Bundle is a classpath object, so the rules on naming and locating bundles are the same as for classes.
That would commonly mean a file in the WEB-INF/classes/resources/application directory. Or, actually, I suspect that it's looking for a bundle named "application" in the WEB-INF/classes/resources directory. Since the point of bundles is to support I18N, the actual bundle name needs to be something like "application.en" for standard English.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Feb 25, 2007
After some research I have added
to the lib directory of JBoss
Now at least I get an error message which makes more sense:
I am trying to emulate an article from a Java magazine which shows that it should be possible to use the variable declared in <h:dataTable var="...">
in method expressions.
Joined: Feb 25, 2007
Thanks for your kind reply.
I have separated controller from model Logic: The Controller has a reference to the model.
If you know a more elegant way I would be very interested to learn it.
By the way my problem is about Method Expression Parameters. Perhaps should have expressed myself more clearly.
JSF apps have little or no user-written Controller code in them. Mostly it uses canned Controller components (the FacesServlet and JSF Tag processors) which are wired up in the Views to their corresponding Models.
Action processors are not Controllers. They're the entry into the business methods that are fired when a command Controller such as a commandButton or commandLink is activated. Or lately, by AJAX, but the same mechanism applies. "Pure" MVC doesn't actually address what to do with data, just how to keep a model and its view in sync via Controllers. In the real world, of course, we do have to jump off into practical applications (business logic), and that's what the Action methods for.
Ideally, one would keep the Actions separate from the Backing properties, but in actual practice, it's usually more trouble than it's worth.
It is not a good idea to attempt to invoke Action methods as though they were general-purpose functions. Although JSF2 makes parameterizing things easier, the original concept was for Action methods to accept no parameters and return a navigation indicator (String). Parameters are neither required nor desirable, because the action processor should be accessing data directly from the Model, not from the View. Putting stuff like that in the View clutters up the View definition, ties it more tightly to a specific usage, adds network overhead, and on top of all that, is a potential security hazard.