Should a complex EL expression be replaced by a single javabean getter?

Question

In JSF if I have a component that conditionally renders based on a number of variables what is the optimal way to handle the render statement... should the logic live in the component declaration or in some form of helper class?

The text woof is only displayed when an animal is an elephant or dog and the animal is not mute.

Option 1:

Implementation in the view:

<h:outputText id="text" value="woof" 
  rendered="#{animal.type == 'elephant' 
                  or animal.type == 'dog' and not(animal.mute)}"/>

or Option 2:

Encapsulation:

<h:outputText id="text" value="woof" rendered="#{animal.barkingAnimal}"/>

with implementation:

public class Animal {
     public boolean isBarkingAnimal() {
         return ("dog".equals(getType()) || "elephant".equals(getType())) && !isMute();
     }
...

So both work... but which is the right way to handle the scenario?

Answer 1

In most cases, it is a simply a matter of taste. If your concern is simply reusing the condition, you could as well do:

<ui:param name="animalCanBark" value="#{animal.type == 'elephant' 
              or animal.type == 'dog' and not(animal.mute)}" />
...
<h:outputText id="text" value="woof" rendered="#{animalCanBark}"/>

This is often useful when the expression you need to write involves more than just one object, say:

<ui:param name="showBarking" value="#{animal.type == 'elephant'
              and not facesContext.validationFailed" />

I think many people prefer to write this type of logic in Java instead of in EL because the Java compiler can do type checking in the Java code (also, most IDEs have better autocompletion for Java then for .XHTML files), which is a concern for some.

Having said that, if it's an information about the model that someday may be used in another place (not just another Facelets/JSF page), that would make a good reason to have it done in your Java code. In the example you gave, the method isBarkingAnimal() gives some information about the model (Animal), which someday might end up being useful when another object (not just another Facelets page) needs to know if a given animal barks. So, I would probably go with that.

Answer 2

As a rule of thumb, try to keep the .xhtml files as logic-free as possible, so they only deal with presentation. So, clearly go for option 2.

Answer 3

Personally, I would use Option #2. While I know it's very possible to solve the problem using EL and gain some bit of reuse across xhtml documents using functions or ui:params it really seems to lack the portability, maintainability and testability of the Java bean implementation.

If a developer is fluent in both EL and Java and owns both the xhtml and Java beans, it doesn't seem to make much sense to use EL to do ANY conditional evaluation with a size > 1.

There just seem to be too many benefits to implementing on the Java side:

• Ability to lean on the IDE + compiler
• Use constants or enums (for "dog" and "bark"), chances are they are being use elsewhere in the code for comparisons as well... if the String value changes it's real fun having to manually replace every occurance of it across a code base
• Instead of having to navigate to the page in question with appropriate data I can exercise logic using unit tests

One of the main arguments I've heard (outside of Stack) in favor of Option 1 is:

"It's a lot easier to see when a component renders if you keep this logic in the view."

I've found that this might be the case for an application in the initial stage of it's life where it's lighter weight and less complicated. However applying this practice on a larger scale and as a smaller application matures it can cause a rats nest of conditionals and become a nightmare to maintain. Here are a couple of examples similar to what I've seen out in the wild:

<h:outputText value="grrr" 
    render="#{animal.type == 'dog' or animal.type == 'cat' or animal.type == 'horse' 
        or animal.type == 'pony' or animal.type == 'mule' or animal.type == 'lion'
        or animal.type == 'tiger' or (animal.type == 'bird' 
        and animal.subType == 'macaw') or .... continue this for another line or two}"
/>

Or my favorite, using multiple components with render conditions that are exclusive of one another to represent the different values that could be displayed:

<h:outputText value="grr" render="#{theMonstrosityFromPreviousExample} />
<h:outputText value="cry" 
    render="#{animal.type == 'human' and animal.subType == 'baby'}" />
<h:outputText value="yo" 
    render="#{animal.type == 'human' and animal.subType == 'teenager'}" />
<h:outputText value="hello" 
    render="#{animal.type == 'human' and animal.subType == 'adult'}"/>

Can up to 4 texts be displayed at once? At first glance you can't tell, a check of each condition will be necessary. As a side note I realize this example is also poor design, as these could be put in a c:choose... but I've seen this before.

At the end of the day this is still theoretically 'view' logic since it determines what actually gets displayed so there's a conceptual argument it should live in the xhtml. The problem that I've found is that including logic like this in the view template can make the layout much harder to understand in the long run and I have yet to see that this method of solving the problem holds any real benefit over using the Java bean implementation.