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.
Joined: Jan 05, 2011
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.
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.
Customer surveys are for companies who didn't pay proper attention to begin with.