This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
So the first thing I am trying to clear up is, is the term 'EL expression' the correct term for each of the following:
I am sure the first is an EL Expression, but I am not so sure what to call the second (the one that uses a pound sign).
This question is complicating a search for info I am doing. I am trying to look at putting two conditions in such an expression - mainly the syntax of the operators. But when I do a search for 'EL Expression operators' or something similar, all I find are examples of EL expressions with $ symbols. I am able to somewhat put it to use, but the uncertainty I have about the topic is making me wonder if I am getting all the info I should. Can someone help clear this up for me? And if anyone has a good link on the topics I mention I would appreciate that.
edit - I know you can also refer to it as a value binding or method binding expression btw - I am just wondering if it also falls under the term 'EL Expression'
True wisdom is in knowing you know nothing - Socrates
There were originally a number of similar-but-not-identical Expression Languages used by various J2EE subsystems. A few years back, they all got merged into a Unified EL.
The "$" notation started with things like JSPs. Basically, a "$" EL expression is read-only and you don't normally use it in JSF. It returns a value.
The "#" notation, on the other hand, is not a value, it's a reference, and therefore provides needed functionality for things like input controls, where simply calculating and displaying is only half the job.
Regardless, I recommend NOT coding complex EL, such as multiple conditions. First of all, because they can be a right royal pain to debug, and secondly, because they imperial the Separation of Concerns at the heart of JSF's Model/View/Controller architecture. If you keep the logic in the Model (backing bean) and leave the View as primarily declarative, you'll enjoy life more because you won't have to hunt around looking for where things get done, you'll know where it's done. The only thing worse than "treasure hunting" is the case where logic is arbitrarily split between the backing bean and the View template and thus as no integral definition.
Customer surveys are for companies who didn't pay proper attention to begin with.
I should have posted my reply to this for others benefit, but I was in a hurry (though you have added more info than I could have so it works out).
But I pulled out my JSF textbook after not finding what I needed online, and came to the same conclusion you point out.
I did decide to not have operators in my rendered attribute, and found a way to just have it in the managed bean. Much cleaner. I just needed a reminder about separating business and presentation layers from that text book. Sometimes I too easily forget some of these cardinal coding habits.
Thanks for your reply though, you still added more info than I had before in the history and usage behind the expressions.