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

  • null objects

    Say I have a "Data" object, which has (amongst other things) a "Price" object, which has an "amount" and a "comment".

    I want to display the "Data" object on a form for the user to edit.

    When it comes to the Price object, can I do something like this?

    <spring:bind path="data.price.amount">
    <input type="text" name="<c:out value="${status.expression}"/>" value="<c:out value="${status.value}"/>">
    </spring:bind>

    <spring:bind path="data.price.comment">
    <input type="text" name="<c:out value="${status.expression}"/>" value="<c:out value="${status.value}"/>">
    </spring:bind>

    The problem I am having is that it is possible for Price to be null. How should I handle that?

    Thanks
    Peter

  • #2
    I have a similar situation. I am extending SimpleFormController, and what I do is in the formBackObject method I check if any of the objects are null and set them to a new instance if they are.

    Comment


    • #3
      Re: null objects

      You should initialize Price to an empty object when it's constructed. In fact, you should be setting all the object's default values upon construction so that client code (such as your controller) doesn't have to screw with it. Remember, always make happy defaults. Never make an object in a state that can crash unless some certain properties are set. Default values really are domain logic. A domain object should know how to initialize itself. If the price really is null, you should have the user tell you it is via the form somehow (like an empty or unparsed field, or a checkbox) and then have the controller set it to the null value when it's processed. In fact, a lot of these concerns can be done in your own custom property editor.

      Comment


      • #4
        I'm not sure if it is a good approach to initialize all object properties at construction to empty objecs. This leads to possible expansion of empty object creation (another constructors are called and complete graphs of unnecessary objects are created) and those created empty objects are in many cases immediatelly discarded when replaced by "real" values from DB and so on.

        So I prefere to do this initialization in another method called initObjs() and I call this method after constructor only when I need such a fully constructed object for example for view.

        Generally before and object is passed to the view some check must be always done, not only for nulls, but for example with Hibernate some properties may point to the same instances of other object, but it may not be ok for view, so clones must be created in this case.

        Comment


        • #5
          Originally posted by kajism
          I'm not sure if it is a good approach to initialize all object properties at construction to empty objecs. This leads to possible expansion of empty object creation (another constructors are called and complete graphs of unnecessary objects are created) and those created empty objects are in many cases immediatelly discarded when replaced by "real" values from DB and so on.

          So I prefere to do this initialization in another method called initObjs() and I call this method after constructor only when I need such a fully constructed object for example for view.

          Generally before and object is passed to the view some check must be always done, not only for nulls, but for example with Hibernate some properties may point to the same instances of other object, but it may not be ok for view, so clones must be created in this case.
          Well, I don't do this for objects that can be null, just the ones that should not be null since Java has no way of specifying this via syntax (like MyObject! definition in other languages). In the null case, I'd just leave it null and when you call the accesser, return a NullObject if the value is null to prevent null pointer exceptions. Have Hibernate or other persistence frameworks access the field rather than the property for these cases. This avoids the extra infrastruture you have suggested.

          Comment

          Working...
          X