JSF Anti-Patterns and Pitfalls

TSS.comより。アンチパターンを必要とするほどJSFの需要がないんだけど，一応メモ。
JSFそのものに馴染みがないんで，PhaseListener問題とかPortlet問題とかよくわからん。

興味深かったのはの"The Map Trick"のところ。

JSPの式言語はあまりにも「プロパティ参照用で〜す」感ありありで式として使うには，ちょっと不便なのだ。「パラメタ付きのメソッド呼べない」ってのを例に上げてたけど，ホントにそうだったっけ？*1
そこで「Mapだけは例外（パラメタ与えられる）」というJSP式言語の特性を利用して，こんなことしてる。

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; }
}

この発想はなかったが，いいのかそれで。:-)

ps.
TSS.comのコメントに「JSF *is* an anti-pattern.」と書いてあって，軽く吹いた。たしかになぁ，Unified ELの遅延評価式がJSFのためだと思うと，少なからず「余計なコトしやがって」とは思うな。
あと，JSPの式言語もGroovy並になってくれ。マジで。

*1:普通のメソッドはNGだけど，getterはパラメタ付きもOKだったような...。遅延評価式も絡むと，また違うのか？