Announcement Announcement Module
Collapse
No announcement yet.
UI Decorators query Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • UI Decorators query

    I'm working on a J2EE (Spring + Hibernate) accounting application which has a fairly complex domain model including classes with nested properties & collections. Eg (getters/setters excluded for brevity):

    Code:
    public class Contract {
    
      private Customer customer;
    
    }
    
    public class Customer {
    
      private List addresses;
    
    }
    
    public class Address {
    
      public String street;
      ..
      ..
      public List contacts;
    
    }
    As part of the data maintenance UI we have to allow users to indicate the selection of one or more items (such as addresses) for application of batch operations, and specify the task to be carried out (delete, archive, etc). For this, we have to have HTML form fields which map onto the Spring MVC form backing object. This means we can't use the domain objects as form backing objects because we don't want to "pollute" DO's with properties which are used only within the UI layer.

    At the moment we are (painstakingly) hand-writing UI decorators for every domain object editable through the UI to add these extra properties but this is proving time-consuming and ugly where we have several levels of nested objects, all of which must be decorated before display then undecorated for handing to hibernate to persist.

    Basically, it's a load of boilerplate code. :? I've tried a couple of solutions:

    I've tried Spring AOP, defining a UIDecorator interface with the appropriate method calls (eg: isSelected()) and an AOP proxy generated from the ProxyFactory, but the BeanWrapper used to map from HTML forms to formBackingObject doesn't recognise the proxy-generated properties as being readable or writable.

    I've also tried a "VirtualBeanWrapper" which wraps any class and allows properties to be referenced as if they were HashMapped values. If a property exists on the wrapped bean the value is read-from or written-to the real bean, otherwise the value is read/written using a HashMap; This way I can reference any property, whether it actually exists on wrapped bean or not, and have a value returned or saved successfully.

    Unfortunately, I've been scuppered from using that method as the way the BeanWrapper parses property names does not allow for nested indexed/mapped properties. Eg: a property reference of 'list[map[key]]' is interpreted as being 'list[map[key' - parsing stops at the first instance of ']' instead of counting the number of '[' versus the number of ']' instances and nesting appropriately.

    This has to be a common problem but after a few days of trawling the net I've not found any likely solutions and have pretty much run out of ideas.

    Can anyone suggest a more elegant alternative to writing all these decorators and save us from having to write dozens of them along with the nested loops we have to use to carry out the decorate/undecorate operations?
Working...
X