Bill Dudney's Blog

JSF: UIComponent.getAttributes() -- good, bad or ugly?

Back in September Allen Holub said that accessors are evil, there was also a long thread on TSS about Allen's article. Then very recently Cedric Beust posted that he thought accessors are here to stay and that Allen Holub was all wrong (I tend to agree with Cedric on accessors but Allen did make a couple of good points). Which all seem to have very little to do with JSF I know but...

Consider the UIComponent.getAttributes() : Map method, which is new in the latest beta release. This method returns a map that gives you get and put access to the JavaBean attributes on your component (all those evil accesors:). This fascinates me and I think its a cool thing to do. Tools have a very simple (java.util.Map) API to use and we as programmers have the accessors for the stuff we need typed access to (its likely to be a little quicker too but probably not called often enough to matter much). So for example;

  public class MyComponent extends UIComponentBase {
    ...
    public static final String FOO = "foo";
    private String foo;
    public void setFoo(String foo) {
      this.foo = foo;
    }
    public String getFoo() {
      return foo;
    }
    ...
  }

  public class MyRenderer extends Renderer {
    public static final String BAR = "bar";
    ...
    public void encodeBegin(FacesContext context, UIComponent component) {
      // instead of casting component to MyComponent I can use the attributes 
      // map to get at 'foo' or I could cast and call getFoo() either way
      // it works the same (the map is of course a bit slower)
      ...
      String foo = (String)component.getAttributes().get(MyComponent.FOO);
      ...
      // even more interesting I can get at the renderer specific
      // values put into the component by the creator of the component
      // (usually a JSP tag) with the same logic
      // Typically I'd be setting the value of bar in a JSP tag
      // also using the map interface like this
      // component.getAttributes().put(MyRenderer.BAR, valueSpecifiedInJSP);
      ...
      String foo = (String)component.getAttributes().get(MyRenderer.BAR);
      ...
      
    }
  }

The spec calls this 'attribute-property transparency'. I like this a lot better than the way that the API was laid out in the EA4 version of JSF. In that world you had to keep everything in a Map and if you wanted accessors they had to delegate to the Map. This is a lot cleaner in my opinion.

Another side effect is that you can just assume that put(Object, Object) will 'just work' and will call the underlying set method when it can and put the value into a map otherwise. Thus we will be able to iterate through properties in a very straightforward way. This comes in very handy in the way JSP custom actions (tags) are implemented. The first example in the spec in section 9.3 shows how this could/should work.

With this API components could conceivably be writen without any accessors and no fields. All the instance data would be stored in the map. I think there is a certian danger of abuse like this.

On the positive side tools can access the whole component without having to know anything about it. This is a key aspect of the tooling requirements behind JSF and was possible in EA4 but uglier.

I've seen this sort of thing done on a limited scale on other projects but I've never seen something like this in a project like JSF (that will be used by lots and lots of people). What are your thoughts on doing this? Will it scale up in terms of usability? Will it get abused so much that we will end up with lots of nasty code? What do you think?

Comments

• another take on accessors
  Maybe people don't like them because their use involves extra coding.

  A proposed change could be something like automatic accessors which can be enabled or disabled on a field by the class author (and potentially overridden).
  The accessor is then automatically called when the name of the field is used.

  class A{
  private String a : set : get;
  }

  might have field a called as
  A b = new A();
  System.out.println(b.a);

  You'd have the encapsulation of accessors without the syntactic overhead.

  Posted by: jwenting on February 16, 2004 at 04:33 AM

• another take on accessors
  Interestingly, this is about how C# works:

  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/vclrfaccessorspg.asp

  Posted by: jimothy on February 16, 2004 at 07:07 AM

• Map is an interface, not a concrete class.
  At the end of the day, it states that it is a Map - not a particular type of Map.

  The backend could easily be some unpleasant reflection gubbins that actually calls get and set dynamically. You can't throw a proper exception on get (so variables are always readonly with no restrictions), but you can put restrictions on get() by throwing IllegalOperationException.

  So, it might make some elements of coding nicer, but it doesn't mean that you're necessarily messing with private instance fields.

  Posted by: crnflke on February 17, 2004 at 03:57 AM

• Map is an interface, not a concrete class.
  Hi crnflke,

  Very true that Map is an interface and the impl of that Map is not specified so the it is free to do cool stuff like reflect to find get/set methods.

  However the abuse potential lies in the fact that instead of having get/set methods that act on private fields the inexperienced developer might see the internal storage (i.e. the hash map) of the Map as sufficient to keep any and all instance data. In a prototype or quick hack situation this would probably be fine but we all know how often quick hacks become production systems so I bring it up in the hopes that we don't end up with tons of ugly code. But instead people think about this possible abuse point early in the JSF adoption phase.

  Posted by: bdudney on February 17, 2004 at 04:15 AM

• another take on accessors
  I have to wholeheartedly disagree with this post. Just because there is more code (ie: get/set methods), does NOT mean more coding. Look into ANY decent IDE and get/set methods are generated in less than a heartbeat.
  If C# wants to expose "private" variables directly, good for them. I'll keep my variable encapsulation thank you very much.

  Posted by: wireframe on February 17, 2004 at 08:21 AM

• wow power leveling
  wow powerleveling
  wow power leveling
  wow gold
  wow items
  feelingame.com
  wow tips
  Most Valuable WOW Power Leveling Service
  wow power leveling faq
  cheap wow power leveling
  wow power leveling
  wow powerleveling
  wow power lvl

  Posted by: wowleveling11 on December 14, 2007 at 05:33 PM

• 网络营销软件
  网络营销软件
  网络营销软件
  群发软件
  群发软件
  ---
  群发软件
  网络营销软件
  论坛群发软件
  网站排名软件
  群发软件
  推广小助手破解版
  论坛群发软件
  网站排名软件
  群发软件
  推荐给你很好的群发软件和信息群发软件和供求群发软件
  推荐给你很好的群发软件和信息群发软件和供求群发软件博客群发软件网络营销软件网络营销软件
  网站排名软件网站排名软件网站优化软件信息群发软件信息群发软件信息群发软件论坛群发软件网站推广软件网站推广软件博客群发软件博客群发软件
  群发软件
  网络营销软件
  网站推广软件
  群发软件群发软件博客群发软件论坛群发软件网络营销软件论坛群发软件
  信息群发软件推广软件网站推广软件网络营销软件网站推广软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件
  网站排名软件
  博客群发软件
  网站排名软件
  网站推广软件
  群发软件信息群发软件
  免费论坛群发软件
  论坛群发软件
  网站排名软件
  免费博客群发软件
  网站推广软件

  群发软件
  博客群发软件
  网站排名软件
  网站推广软件
  群发软件信息群发软件
  免费论坛群发软件
  论坛群发软件
  网站排名软件
  免费博客群发软件
  博客群发软件
  信息群发软件
  论坛群发软件
  信息群发软件
  博客群发软件
  qq群发软件
  邮件群发软件
  博客群建软件
  企业名录搜索软件
  信息群发软件
  邮件群发软件
  论坛群发软件
  博客群发软件
  网站推广软件
  网络营销软件
  全能营销破解版
  网络营销软件
  论坛群发软件
  论坛群发软件
  论坛群发软件
  网络营销软件
  信息群发软件
  信息群发软件
  信息群发软件
  群发软件
  论坛群发软件
  

  Posted by: sun98989 on December 30, 2007 at 05:54 AM

This work is licensed under a Creative Commons License.