1 Reply Latest reply on Oct 16, 2006 5:05 AM by aloubyansky

    Still got problems with groups

      I still have an issue mapping groups.

      This relates to the work being done here:
      http://www.jboss.com/index.html?module=bb&op=viewtopic&t=92129

      It is relatively easy to map elements/types, since if you have:

      xsd:
      <xsd:type name="parent">
       <complexType>
       <sequence>
       <xsd:element ref="child"/>
       </sequence>
       </complexType>
      </xsd:type>
      
      xml:
      <parent>
       <child/>
      </parent>
      
      java
      @SchemaType(name="parent")
      public class ParentType
      {
       @SchemaProperty(name="child")
       public String whatever;
      }
      


      You can just add an interceptor.
      I currently have two generic interceptors:
      1) For plain properties
      2) For collection properties

      These are generalisations of the interceptors I have written
      before in bean schema binding.

      However for a group what you want to do is create buckets/holders,
      e.g.
      xsd:
      <xsd:group name="parent">
       <sequence>
       <xsd:element ref="element1" maxOccurs="unbound"/>
       <xsd:element ref="element2" maxOccurs="unbound"/>
       <xsd:element ref="element3" maxOccurs="unbound"/>
       </sequence>
       </complexType>
      </xsd:type>
      
      xml:
      <parent>
       <element1/>
       <element1/>
       <element2/>
       <element3/>
      </parent>
      
      java
      @SchemaType(name="parent")
      public class ParentType
      {
       @SchemaHolder(name="element1")
       public Bucket1 b1;
       @SchemaHolder(name="element2")
       public Bucket1 b1;
       @SchemaHolder(name="element3")
       public Bucket1 b1;
      }
      


      I originally tried to do this a custom particle handler on the group that
      extended and delegated to the default handler
      which basically replaced the parent object with the relevant bucket.

      But this has two problems that boil down to the same problem:
      1) The information you get at the end does not tell you which bucket
      finished.
      2) The particle handler is only invoked at the beginning and end of the group, not the beginning and end of the buckets/subparticles.

      So currently, it doesn't seem like there is anyway other than
      to add metadata to the elements to get this bucket processing.

      But this fails, because if like the example above, the elements
      are global, you may be using the element somewhere else
      than the group.

      In fact, there is a way.
      It basically means looking at all types and elements that
      use the group and adding interecptors for the buckets
      to each type and element found.

      This isn't very nice and seems like a hack to me.
      I'd prefer it, if it was possible to just add metadata/interceptors to the
      group that would automatically get used by referencing types/elements
      as it went through the stack/model during parsing.

      P.S. To explain the idea of a "SchemaHolder"

      This is intended to introduce something into the xml model
      that isn't really there, but it is in the java model.

      If it were, the xml would be written like:
      <parent>
       <bucket1>
       <element1/>
       <element1/>
       </bucket1>
      etc.
      


      The holder/bucket can be either collection or plain java type.

      Also potentially in future, the holder might completely rework
      the object into a different type for injection onto the parent.

      e.g. The holder is a collection, but the parent has been "denormalized"
      public class Holder
      {
       public Collection<Element> elements;
      }
      public class Parent
      {
       public Element1 e1;
       public Element2 e2;
      }
      


        • 1. Re: Still got problems with groups
          aloubyansky

          Yes, there is a problem with global components (elements, attributes, groups). There should be a notion of local metadata/handlers/interceptors that are applied at their "use" in the schema. It's also similar to handling wildcard content. Especially when it's from a different schema.

          Also, for starting/ending buckets, there are callbacks for start/end repeatable term events. But they are not exposed at the moment as a public API.