JiBX
  1. JiBX
  2. JIBX-235

Inconsistency when using pre-set and post-set methods with Object argument

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: JiBX 1.1.6
    • Fix Version/s: None
    • Component/s: core
    • Labels:
      None
    • Number of attachments :
      0

      Description

      In an example like this:

      binding: -----
      <mapping class="parent">
      <structure name="name1" field="field1" type="type1" post-set="postset" />
      <structure name="name2" field="field2" type="type2" />
      <collection name="collection" field="field3" item-type="type3" />
      </mapping>

      <mapping class="type1" abstract="true">
      </mapping>

      <mapping class="type2" post-set="postset" abstract="true">
      </mapping>

      <mapping class="type3" post-set="postset" name="name3">
      </mapping>


      XML: —
      <parent>
      <name1 />
      <name2 />
      <collection>
      <name3/>
      </collection>
      </parent>

      The postset(Object) method of the class type1 will be called as expected, with the Object parameter indicating the "parent" node. However, for type2, the "name2" node will be passed in. For type3, the Object parameter will be pointing to the Collection instance representing the "collection" node, which I find to be logical.

      I have seen two workarounds:
      1. Always specify the 'post-set' method on the 'structure' level rather than on the abstract mapping level. That is a bit brittle in my case and doesn't solve the problem (easy to forget it on one structure).
      2. For the 'type2' case, specify a post-set method that takes the IUnmarshallingContext parameter and go one step deeper in the hierarchy to find the correct containing object. This works, but means that I need to treat cases 1 and 3 one way, and 2 in another.

      Suggested solution: make case 2 work like case 1.

        Activity

        Hide
        Dennis Sosnoski added a comment -

        This is somewhat ugly, but cleaning it up in the current code generation is probably impractical. It'll be addressed for 2.0.

        Show
        Dennis Sosnoski added a comment - This is somewhat ugly, but cleaning it up in the current code generation is probably impractical. It'll be addressed for 2.0.
        Dennis Sosnoski made changes -
        Field Original Value New Value
        Component/s core [ 10676 ]
        Assignee Dennis Sosnoski [ dsosnoski ]

          People

          • Assignee:
            Dennis Sosnoski
            Reporter:
            Petter Mhln
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: