Announcement Announcement Module
No announcement yet.
Tansfer Objects for dwr/ajax? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Tansfer Objects for dwr/ajax?

    Hi all,

    I'm exposing some beans via DWR to an ajax application (extjs). Now I need to wrap the bean somewhere and manipulate some properties to expose it to the view in a proper format.


    Bean representing one of many fixed prices of something.
    class PriceBean{
      private Long id
      private String priceKey
      private String description
    priceKey is a fixed String representing the price with a special prefix. Like price399.

    Before I expose it to the view, I need to translate the priceKey to a human readable String like 3.99€ (depending on the currency) and I do not really need all properties in the view.

    With dwr I'm able to expose beans only, so my first idea is to write some kind of "Transfer Object". But I don't think this is really a good way to solve that issue from architectural perspective. In fact it's not really the Transfer Object Pattern, since I'm not combining properties from different beans into a single bean.

    My question is: Is there a better fitting pattern? How could a "nice" solution look like?

    A nicer option might be to extend the existing bean with behavioural methods like getHumanReadablePrice to return the data in a format which fits. But I can't touch this beans easily.


  • #2
    I have had good experiences with transferring objects to AJAX clients using JSON. The libraries on will allow you to convert most beans into a JSON representation. Or you can manually build out the JSON object if you want to insert UI specific data.


    • #3
      Hi Andrew,

      that's not my issue. The problem is a bad domain model, actually it's a good example of an anemic domain model and the beans don't represent all information I need. Actually they're partly not aware of the information and behaviour I want to expose.

      I solved it by writing some adapter beans with little behaviour, which hold an instance of the original bean and are prefilled by the service layer with all additional relations.
      Not very beautiful, but refactoring the domain model is sadly not an option here (at least for the moment) as so often in projects.