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.
