JSF Anti-Patterns and Pitfalls

I'll go far enough to say there is never an excuse to use the Map Trick. Like the Validating Setter, the Map Trick begins with a small limitation of the spec. JSF EL and Unified EL do not support parameterized method invocation of managed bean methods. The closest feature available is static method invocation via JSP EL or Facelets. Tapestry developers, or anyone else familiar with the OGNL expression language, are often disappointed to learn this.

The Map interface is the only exception. JSP EL, JSF EL and Unified EL all support invocation of the get method, a parameterized method of the Map interface.

#{myManagedBean.silvert} // pulls 'silvert' from managed bean Map
#{param['foo']}          // pulls 'foo' request parameter

Some developers have implemented their own Map to take advantage of this.

public class MapTrick implements Map {

 public Object get(Object key) {

  return new BusinessLogic().doSomething(key);

 }

 public void clear() { }
 public boolean containsKey(Object arg) { return false; }
 public boolean containsValue(Object arg) { return false; }
 public Set entrySet() {return null; }
 public boolean isEmpty() { return false; }
 public Set keySet() { return null; }
 public Object put(Object key, Object value) { return null; }
 public void putAll(Map arg) { }
 public Object remove(Object arg) { return null; }
 public int size() { return 0; }
 public Collection values() { return null; }

}

When the EL Resolver invokes the get method the parameter is then used by business logic. I once visited a project where an architect had created an entire mini framework around the Map Trick. Needless to say many of the developers were complaining of severe coupling between the view and model.