You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Gary VanMatre (JIRA)" <ji...@apache.org> on 2006/06/13 04:40:16 UTC

[jira] Resolved: (SHALE-187) Add the ability for tooling to digest clay component descriptions

     [ http://issues.apache.org/struts/browse/SHALE-187?page=all ]
     
Gary VanMatre resolved SHALE-187:
---------------------------------

    Fix Version: 1.0.3
     Resolution: Fixed

Created an AbstractBean that has the description and then changed the inheritance of the config beans to extend the AbstractBean.  A SymbolBean was created and the AttributeBean change to extend the new SymbolBean.  The symbols map now returns a SymbolBean instead of a String.  This might break existing code that accesses the symbols maps directly.  A new DesigntimeTestCase was added to demonstrate how to toggle on and off the config bean description population.  The descriptions are inherited for all the config beans except the symbols.

> Add the ability for tooling to digest clay component descriptions
> -----------------------------------------------------------------
>
>          Key: SHALE-187
>          URL: http://issues.apache.org/struts/browse/SHALE-187
>      Project: Shale
>         Type: Improvement

>   Components: Clay
>     Versions: Nightly
>  Environment: Linux, Windows
>     Reporter: Ryan Wynn
>     Assignee: Gary VanMatre
>     Priority: Minor
>      Fix For: 1.0.3

>
> Description is an element of the shale-clay.dtd.  Currently it is used to document components, attributes, symbols, etc., but is not digested by the ClayXmlParser.  It would be beneficial for design time tooling to have the option to create an instance of the ClayXmlParser that would digest these descriptions and associate them with their corresponding meta-beans.
> I believe that the solution to this would be to add a description property to the meta-beans and add the digester rules necessary to populate this attribute during the parse.  The default would be to not parse descriptions, but a design time tool could turn the parsing on.
> This solution may also involve adding some sort of SymbolBean akin to AttributeBean in order to hold the description attribute.  Currently symbol metadata is parsed into a HashMap of name-value pairs.  This leaves no place to store the description.  Attribute metadata on the other hand is stored in AttributeBeans which along with the other meta beans allow for a place to hold the description.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira