You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Cale Scholl <ca...@oracle.com> on 2009/12/15 01:58:07 UTC

ColorConverter performance, and client converter class organization

There are two issues I'd like to discuss:

1. 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. We should have 
hard-coded default values for these attributes, e.g.:
DEFAULT_PATTERN = ["RRGGBB","#RRGGBB","r,g,b"];
DEFAULT_TRANSPARENT_ALLOWED = true;

Then, we only write out said attributes if their value is not equal to 
the default value.

I did a "find in files" for _cfs and _cfts, and they're only referenced 
in two functions:

  ColorFieldFormat.js:
   
  function _getColorFieldFormat(
    colorField)
  {
    var name = colorField.name;
    if (name && _cfs)
    {
      var format = _cfs[name];
      var trans  = _cfts[name];
      if (format || trans)
        return new TrColorConverter(format, trans);
    }

    //return new TrColorConverter();
    // change to:
    return new TrColorConverter(DEFAULT_PATTERN, 
DEFAULT_TRANSPARENT_ALLOWED)
  }

and:

    ColorField.js

    function _lcp()
    var patterns = _cfs[nameInForm];
    // add this:
    if (patterns === undefined)
      patterns = DEFAULT_PATTERN;
    ...
    var allowsTransparent = _cfts[nameInForm];
    // add this:
    if (allowsTransparent === undefined)
      allowsTransparent = DEFAULT_TRANSPARENT_ALLOWED;

Note that comments in the above code indicate my suggested changes.

2. The Converter's are in trinidad-api, but the ClientConverter's are in 
trinidad-impl. Why?  Are we purposely trying to prevent people from 
extending our ClientConverter's in order to create their own custom 
ClientConverter's?

Thank you,
Cale