javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-2668

Metadata for nested cc:attribute are not exposed

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: composite components
    • Labels:
      None
    • Environment:

      All Mojarra versions

      Description

      I'm a developer of a custom composite component library. Based on this great article from Ed Burns http://weblogs.java.net/blog/edburns/archive/2009/09/02/jsf2-composite-component-metadata?force=674 I implemented a nice documentation framework which extracts all metadata from the VDL. Everything is ok, but BeanInfo object

      Resource ccResource = context.getApplication().getResourceHandler().createResource(resourceName, libraryName);
      BeanInfo metadata = vdl.getComponentMetadata(context, ccResource);
      PropertyDescriptor attributes[] = metadata.getPropertyDescriptors();
      ...
      

      doesn't expose metadata for nested cc:attribute. Metadata structure for attributes is flat, only top cc:attribute are exposed in BeanInfo's property descriptors. That means, if you have e.g.

      <cc:interface ...>
          <cc:attribute name="exportCfg" ...>
              <cc:attribute name="fileName" .../>
              ...
          </cc:attribute ...>
      </cc:interface>
      

      the metadata for "fileName" are not present. I don't know if it's a bug / improvement or just a lack of the specification. I read the section 3.6.2.1 in the spec. For me it is a bug because the spec. says "Any attributes declared by the composite component author using <composite:attribute/ > elements must be exposed in the array of PropertyDescriptors returned from getPropertyDescriptors() on the composite component BeanInfo."

        Activity

        Hide
        Ed Burns added a comment -

        I'm glad to see someone using the metadata interface, and I appreciate your compliment about the article.

        Recall the design intent of <cc:attribute>: document the allowable attributes so the page author (or page author's agent) knows what they can type. For example:

        comp.xhtml:

        <cc:interface>
        <cc:attribute name="exportCfg" />
        </cc:interface>

        This means someone can do:

        <my:comp exportCfg="export value" />

        Now, if we have:

        comp.xhtml:

        <cc:interface ...>
        <cc:attribute name="exportCfg" ...>
        <cc:attribute name="fileName" .../>
        </cc:attribute ...>
        </cc:interface>

        This means someone can do:

        <my:comp exportCfg.filename="export value" />

        But that doesn't make sense, markup wise.

        Show
        Ed Burns added a comment - I'm glad to see someone using the metadata interface, and I appreciate your compliment about the article. Recall the design intent of <cc:attribute>: document the allowable attributes so the page author (or page author's agent) knows what they can type. For example: comp.xhtml: <cc:interface> <cc:attribute name="exportCfg" /> </cc:interface> This means someone can do: <my:comp exportCfg="export value" /> Now, if we have: comp.xhtml: <cc:interface ...> <cc:attribute name="exportCfg" ...> <cc:attribute name="fileName" .../> </cc:attribute ...> </cc:interface> This means someone can do: <my:comp exportCfg.filename="export value" /> But that doesn't make sense, markup wise.
        Hide
        ova2 added a comment -

        Sorry, I didn't understand. I meant the following. With CC we can use nested cc:attribute and specify what the top level object looks like. If we write

        <cc:interface ...>
            <cc:attribute name="exportCfg" ...>
                <cc:attribute name="fileName" type="..." shortDescription="..." required="..."/>
                ...
            </cc:attribute ...>
        </cc:interface>
        

        we mean, there is a top level object (class) exportCfg with an attrribute "fileName". The attribute "fileName" has metadata describing itself, such as "type", "shortDescription", etc. I would like to access these metadata because I automatically generate a documentation for JSF developers (using my library) from the cc:interface with all its attributes, clientBehaviors, valueHolders, facets, ... My problem is now: PropertyDescriptor for "exportCfg" has nothing for nested attributes, so that I can not read metadata for "fileName", etc. and generate the complete documentation. The way with nested attributes is not forbidden. Right? Right. But presented metadata are "flat". I read the MyFaces had the same issue in the past. Not tested if they could fix it, but they were at least aware of this.

        Show
        ova2 added a comment - Sorry, I didn't understand. I meant the following. With CC we can use nested cc:attribute and specify what the top level object looks like. If we write <cc:interface ...> <cc:attribute name= "exportCfg" ...> <cc:attribute name= "fileName" type= "..." shortDescription= "..." required= "..." /> ... </cc:attribute ...> </cc:interface> we mean, there is a top level object (class) exportCfg with an attrribute "fileName". The attribute "fileName" has metadata describing itself, such as "type", "shortDescription", etc. I would like to access these metadata because I automatically generate a documentation for JSF developers (using my library) from the cc:interface with all its attributes, clientBehaviors, valueHolders, facets, ... My problem is now: PropertyDescriptor for "exportCfg" has nothing for nested attributes, so that I can not read metadata for "fileName", etc. and generate the complete documentation. The way with nested attributes is not forbidden. Right? Right. But presented metadata are "flat". I read the MyFaces had the same issue in the past. Not tested if they could fix it, but they were at least aware of this.
        Hide
        ova2 added a comment -

        Nested attributes defines a contract. E.g. "exportCfg" object should have "fileName" as setter / getter. This helps prevent bugs because library users see in the docu how they have to implement "exportCfg".

        Show
        ova2 added a comment - Nested attributes defines a contract. E.g. "exportCfg" object should have "fileName" as setter / getter. This helps prevent bugs because library users see in the docu how they have to implement "exportCfg".

          People

          • Assignee:
            Unassigned
            Reporter:
            ova2
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: