Silva Issue Tracker Archive: Issue1704

 This tracker has been migrated to Launchpad. Please post new messages at:
Title Problem with CheckBoxFields as parameters in CodeSources
Priority bug Status testing
Superseder (list) Nosy List flynt, kitblake, lbenno, thisfred, wim (list)
Assigned To wim Topics Silva-1.5, Silva-1.6, Silva-2.0 (list)

Created on 2007-02-27.16:22:57 by lbenno, last changed 2007-03-19.17:14:32 by thisfred.

msg9286 (view) Author: thisfred Date: 2007-03-19.17:14:31
Should be fixed, please test with existing code sources.
msg9285 (view) Author: kitblake Date: 2007-03-19.12:48:10
The Code Source is rendered with "External Source is broken" and the error is
listed as the name of the first field that doesn't have a value (or element)
stored in the xml.
msg9284 (view) Author: thisfred Date: 2007-03-19.12:35:55
What is the error you are getting, if any, or else what is the undesired behaviour?
msg9283 (view) Author: kitblake Date: 2007-03-19.09:35:49
This revision:
has broken many of the Code Sources in the Infrae site. The problem is, many of
the older ones don't have a value, even an empty one, stored in the xml if a
field was empty.

There are probably lots of old Code Sources out there with the same non-existent
msg9278 (view) Author: wim Date: 2007-03-15.18:08:06
Ok did some testing and my conclusion is that it wrorks fine now with xslt
rendering on but not with xslt rendering off.
How did I test?
I added 2 checkboxes to the cs Insert Formulator Form chkboxon and chkboxoff.
chkboxon is checked (True/1) and chkboxoff is not checked (False/0)
These are also the values I can see in Kupu.

In a ZPT i do the following tests:
<h1 style="color: grey">Checkbox on: <span tal:content="chkbox_on" /> </h1>
<h1 style="color: grey">Checkbox off: <span tal:content="chkbox_off" /> </h1>

With xslt i get the correct booleans true for the first and false for the second
With xslt I get twice false, which is not correct.
msg9271 (view) Author: thisfred Date: 2007-03-14.12:15:29
I've fixed this in SilvaExternalSources. Wim, can you take testing the xslt
rendering of checkbox code sources along? (make sure to use both false and true
values to see whether both work.)
msg9263 (view) Author: thisfred Date: 2007-03-13.12:24:14
Ok, I'll have a look at that, shouldn't be too hard to fix.
msg9260 (view) Author: lbenno Date: 2007-03-13.11:23:20
I found out that there's something missing with xslt rendering enabled: the
value of the CheckBoxField is not interpreted as expected.
msg9256 (view) Author: thisfred Date: 2007-03-12.18:13:45
Many thanks Benno! We'll test this a.s.a.p.

Wim: can you have a look at this on tuesday, keeping in mind my testing notes?
Tackle me if anything's unclear.
msg9255 (view) Author: lbenno Date: 2007-03-12.18:02:27
I checked my proposed changes in.
I've made the checkins into:

both trunk and SilvaDocument-1.5 branch.



I had to fix the test in SilvaDocument-1.5 branch for that it went through, but
didn't add a special test for the issue.
msg9244 (view) Author: thisfred Date: 2007-03-08.17:34:40
I've reviewed the changes, and I see no obvious problems, so I would say check
them in. (Note that for 1.6 the change in kupusilvatools.js has to happen in
Silva/kupu, and not in kupu itself.) If you've done that, please set this issue
to testing, and I will assign it to someone here to test.


- Run the silva tests, I expect the change may impact the xml export/import
tests. If not, we may want to add tests for checkbox parameters.
- Test Codesources having checkbox parameters with and without xslt rendering,
(once the other issue with that is fixed) to see whether the codesources behave
as expected.
msg9231 (view) Author: lbenno Date: 2007-03-07.14:43:25
I can check-in the code if you whish. I hesitate to do this because of the
change in the SilvaXML this implies and the possibly unpredictable consequences
of such a change.
msg9228 (view) Author: lbenno Date: 2007-02-27.16:22:56
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.:

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

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

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

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

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

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

- SilvaExternalSources\ [get_rendered_form_for_editor()]:
Added on line 174-175 (needed to display the correct checkbox value in the kupu
            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">
However, Firefox changes the attribute names to lowercase, e.g.:
<div source_id="new_cs" class="externalsource" amiactive="1">
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
Date User Action Args
2007-03-19 17:14:32thisfredsetmessages: + msg9286
2007-03-19 12:48:11kitblakesetmessages: + msg9285
2007-03-19 12:35:56thisfredsetmessages: + msg9284
2007-03-19 09:35:51kitblakesetmessages: + msg9283
2007-03-15 18:08:08wimsetmessages: + msg9278
2007-03-14 12:15:30thisfredsetmessages: + msg9271
2007-03-13 12:24:14thisfredsetmessages: + msg9263
2007-03-13 11:23:21lbennosetmessages: + msg9260
2007-03-12 18:13:47thisfredsetstatus: chatting -> testing
nosy: + wim
messages: + msg9256
assignedto: thisfred -> wim
2007-03-12 18:02:28lbennosetmessages: + msg9255
2007-03-08 17:34:41thisfredsetmessages: + msg9244
2007-03-07 14:43:28lbennosetstatus: unread -> chatting
nosy: flynt, thisfred, kitblake, lbenno
messages: + msg9231
2007-02-27 16:22:57lbennocreate