Silva Issue Tracker Archive: Message9228

 This tracker has been migrated to Launchpad. Please post new messages at: https://bugs.launchpad.net/silva.
Author lbenno
Recipients flynt, kitblake, lbenno, thisfred
Date 2007-02-27.16:22:56
Content
When using CheckBoxFields as parameters in CodeSources, such parameters do not
behave as expected. The main reason is that such CodeSource parameters are
represented as parameter nodes with a type attribute having the value "string"
and the child text node with values either 'True' or 'False'. When the SilcaXML
renderer interpretes such nodes, it converts the text node to a string value
using the ustr() method. Such a value, then, is passed to the
CheckBoxField.render() method that renders it to '<input type="checkbox"
name="field_amIActive" checked="checked"  />' in every case.

I propose the following solution to overcome this problem:
Parameters with CheckBoxFields are of type 'boolean' (i.e. have the type
attribute 'boolean') instead of 'string'. In addition, the child nodes of such
parameters will by 0/1 instead of False/True. E.g.:

old:
================
<doc>
<source id="myCodeSource">
  <parameter key="amIActive" type="string">False</parameter>
</source>
</doc>
================

new:
================
<doc>
<source id="myCodeSource">
  <parameter key="amIActive" type="boolean">0</parameter>
</source>
</doc>
================

To achieve this, the following four files have to be adjusted:

- SilvaDocument\widgets\element\doc_elements\source\mode_edit\save_helper.py:
Added on line 68-72 (this will store the value in the suggested way in the
SilvaXML):
=====================================
            if field.meta_type == "CheckBoxField":
                vtype = 'boolean'
                value = str(int(value))
            else:
                value = ustr(value)
=====================================

- kupu\silva\kupusilvatools.js:
Added on line 2179-2183 (this will store the value in the suggested way in the
SilvaXML):
                    }
                    else if (child.getAttribute('type') == 'bool') {
                    	value = (value == "True" ? 1 : 0);
                        attrkey = key + '__type__boolean';
                    };


- SilvaDocument\_externalsource.py [getSourceParameters()]:
Added on line 26/27 (needed to display the correct chechbox value in the forms
editor):
=====================================
        elif type == 'boolean':
            value = int(value)
=====================================


- SilvaExternalSources\ExternalSource.py [get_rendered_form_for_editor()]:
Added on line 174-175 (needed to display the correct checkbox value in the kupu
editor):
=====================================
            elif field.meta_type == "CheckBoxField":
                value = int(value)
=====================================

Caveats - things to know:
Using the kupu editor to edit CodeSources having parameter with mixed case field
ids may lead to unexpected behaviour with Firefox (tested with Vers. 1.5): 
Reason: Before putting the changes to the server, kupu stores the changes
temporarily in attributes that are elements of the codesource node:
===
<div source_id="new_cs" class="externalsource" amIActive="1">
...
</div>
===
However, Firefox changes the attribute names to lowercase, e.g.:
===
<div source_id="new_cs" class="externalsource" amiactive="1">
...
</div>
===
Now, when the form in the CodeSource toolbox is refreshed,
ExternalSource.get_rendered_form_for_editor() is called. This method retrieves
the form field using the field ids found in the request. However, if the request
contains a field id 'amiactive' instead of 'amIActive', no field is found and
the form field is rendered with default value. In the case of a CheckBoxField,
the CheckBox is rendered unchecked in every case, irrespective of the effective
value. (IE7 processes CodeSource parameters with mixed case ids correctly).
Therefore, it is a good advise to use only lower case ids for CodeSource parameters.
Maybe, this problem and workaround should be mentioned somewher in the
documentation.
History
Date User Action Args
2007-02-27 16:22:57lbennosetrecipients: + lbenno, flynt, thisfred, kitblake
2007-02-27 16:22:57lbennosetmessageid: <1172589777.23.0.266641166783.issue1704@infrae.com>
2007-02-27 16:22:57lbennolinkissue1704 messages
2007-02-27 16:22:57lbennocreate