color converter renders extra JS -------------------------------- Key: TRINIDAD-1688 URL: https://issues.apache.org/jira/browse/TRINIDAD-1688 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.12-core Reporter: Cale Scholl Priority: Minor
MAIN ENHANCEMENT: In trinidad-impl ColorConverter.getClientScript we have: ---------- String[] patterns = getPatterns(); buff.append("_cfs[\""); buff.append(clientId); buff.append("\"]="); if (patterns.length == 1) { buff.append("\""); buff.append(patterns[0]); buff.append("\""); } ... if (isTransparentAllowed()) { buff.append("_cfts[\""); buff.append(clientId); buff.append("\"]=true;"); } ---------- This writes out the pattern used by the client color converter, and specifies whether the converter allows transparency. But guess what? In trinidad-impl ColorConverter.getClientConversion (this writes out the string used to construct the converter on the client), the exact same information is written out. It's even stored on the TrColorConverter instance, as demonstrated via the following: ---------- function TrColorConverter( pattern, allowsTransparent, patternsString, messages) { ... this._allowsTransparent = allowsTransparent; this._pattern = pattern; } ---------- So there's no need to store this information on the page; we just need access to the TrColorConverter instance. As far as I can tell, the information stored on the page is only used when you click on the inputColor's color picker (this launches a chooseColor in a new window). The color picker's onClick behavior is attached to a function in ColorField.js called _lcp, and that calls a function in ColorFieldFormat.js called _getColorFieldFormat; we'd have to figure out how to access the TrColorConverter instance from within both of these functions. These functions have access to the inputColor id, so it should be possible to obtain the TrColorConverter instance using that. SECONDARY ENHANCEMENT: When we have a default converter (via SimpleInputColorRenderer.getDefaultConverter), there's no need to write out the client-side converter constructor string (getClientConversion should return null); since we know what the default values are ahead of time and none of them need to be localized, we can hard-code the constructor string on the client: new TrColorConverter(new Array('#RRGGBB','r,g,b'), false, '#RRGGBB r,g,b', {}) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.