File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes JSF and the fly likes c:choose not working with ajax Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "c:choose not working with ajax" Watch "c:choose not working with ajax" New topic

c:choose not working with ajax

Rory Gilfillan

Joined: Jan 05, 2011
Posts: 3

I used the c:choose to decide whether a page number should be rendered as <strong> or as a link, but when the AJAX executes the c:choose doesn't run. It seems to only run the first time that it is loaded. I know i'm not supposed to put any logic in the view but this really something simple. I'm really getting irritated with JSF why do they half implement something. If your not supposed to put logic in the backing beans or in the view where are you supposed to put it. I feel like this MVC is like a straight jacket.


Rory Gilfillan

Joined: Jan 05, 2011
Posts: 3
I overcome that problem by doing this:

But I don't see why JSF can't handle such simple logic.

I have another problem that when the URL has a some parameters on the end the whole page reloads instead of the portion that i told AJAX to reload.

Initially I had a problem that after AJAX reloaded the part of the page I requested, then the whole page would reload. I solved that by putting the JSF library files in WEB_INF/lib directory. I'm using eclipse and the files are already on the build path so it didn't seem necessary. I had a tutorial where the AJAX was working properly and libraries in WEB_INF/lib seemed to be the only difference . I also used the tutorials version of the libraries, so i am not sure if that was the problem.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17410

Rory Gilfillan wrote:But I don't see why JSF can't handle such simple logic.

Because JSF is a fairly pure implementation of Model/View/Controller and logic is supposed to be on or behind the Controller, and NOT on the View.

And in particular, putting any JSTL on a JSF View is usually more grief that it's worth. JSF is quite capable of doing just about anything that JSTL does all by itself and the overall excuciation is usually much less once you get used to a slightly different view of how things should be done.

I mentioned that logic is mostly something to be kept off of the View, but View Logic - stuff like enable/disable, render/hide is an exception, Still, any complex view logic should be pushed to the backing bean, for 3 reasons:

1. If you type as badly as I do, the compiler can catch most of the blatantly fat-fingered stuff in development instead of having it blow up in production.

2. Complex EL expressions are not only cumbersome, but you set people up for having to play hide-and-seek on the logic. Was it on the View? Was it on the Bean? Is it split between the two?

3. The bean knows more about the internal workings of the system. If you set up a simple "isAmountRendered()" method, for example, you can code any logic you want inside it and the View won't be affected if it changes.

An IDE is no substitute for an Intelligent Developer.
I agree. Here's the link:
subject: c:choose not working with ajax
jQuery in Action, 3rd edition