Re: [PW-dev] Re: Widget-0.03

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

At 11:19 PM 7/8/2001 +0800, Gunther Birznieks wrote:
>I pretty much like all of this.
>
>But I don't quite understand where background-color is turned into 
>backgroundColor and why. Is the widget code then taking this internal 
>capital case and turning it back into background-color when it actually 
>generates the HTML?
>
...

Hi,

Short answer is...

  where: It is transformed in Widget::HTML::Stylizable
         See the translation table in %style_attrib.
         (It is not convention magic which changes internal caps to
         dashes.) (Please note that the next version, 0.04, will
         probably change the way I implement styles.)

  why:   I needed to choose some convention for multi-word attributes,
         and the internal-caps style (backgroundColor) works with
         named parameter conventions (-backgroundColor => '#ffffff')
         (with no quotes) whereas internal dashes do not 
         (-background-color => '#ffffff') (which fails because "dash"
         is the "minus" operator).

The longer answer includes the following discussion:

  What should the attribute be called in the Perl API (the Perl
     Widget Library) if it maps directly to an attribute of an underlying
     physical rendering technology?

Example:

The background color of something might be translated into

   * bgcolor (HTML of <body>, <td>)
   * background-color (CSS style sheets and HTML STYLE='background-color:
#ffffff')
   * backgroundColor (Javascript method of setting the attribute)

There are any number of rendering technologies which may be used by a given
widget.  However, we should not need to know the particulars about it.
Therefore, we should scan the potention rendering technologies (for naming
precedents so that we don't add yet another naming precedent for no reason).
Then we should *adopt* that convention as the *native* convention for the
attributes of widgets in the PWL.

Therefore, I chose the Javascript-style internal-caps convention for all
PWL attributes because:

 a. it mirrors a commonly used internal rendering technology (Javascript)
 b. it works with Perl for named parameter syntax

Stephen