[TRINIDAD-850] Virtual Attributes in Component Generator hard-code accessKey

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Won't Fix
• Affects Version/s: 1.2.5-plugins
• Component/s: Plugins
• Assignee: Matt Cooper
• Reporter: Matt Cooper
• Due: 20/Dec/07
• Created: 05/Dec/07 17:45
• Updated: 05/Dec/07 22:59
• Resolved: 05/Dec/07 22:59

Description

Whenever a Trinidad component has a text/label/value and a corresponding accessKey, a third attribute is added to the tag to simplify the assignment of the first two attributes, e.g. to help with translations. This attribute is identified as a virtual attribute meaning that it only exists on the tag and not on the component. The names of these attributes are "textAndAccessKey", "labelAndAccessKey", or "valueAndAccessKey".

The plug-in code org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.TrinidadComponentTagGenerator._getAccessKeyPropertyKeys() unfortunately hard-codes "accessKey" as the secondary non-virtual attribute instead of searching for "And" and then using the leading and the following strings around it.

This hard-coding becomes a problem when you have components where you need to define multiple text/label/value and accessKey pairs. Let's say these are the virtual attribute names desired:

• yesTextAndAccessKey
• noTextAndAccessKey
• cancelTextAndAccessKey

These separate out into these non-virtual attributes:

• yesText, accessKey
• noText, accessKey
• cancelText, accessKey

Notice the collisions. Instead, this is the desired separation is:

• yesText, yesAccessKey
• noText, noAccessKey
• cancelText, cancelAccessKey