Problem with CheckBoxFields as parameters in CodeSources

Bug #101818 reported by Benno Luthiger
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Silva
Fix Released
Medium
Andy Altepeter

Bug Description

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.

Revision history for this message
Benno Luthiger (benno-luthiger) wrote :

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.

Revision history for this message
Eric Casteleijn (thisfred) wrote :

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.

TESTING NOTES:

- 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.

Revision history for this message
Benno Luthiger (benno-luthiger) wrote :

I checked my proposed changes in.
I've made the checkins into:

SilvaDocument:
both trunk and SilvaDocument-1.5 branch.

SilvaExternalSources:
trunk.

kupu:
Silva/trunk/kupu.

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.

Revision history for this message
Eric Casteleijn (thisfred) wrote :

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.

Revision history for this message
Benno Luthiger (benno-luthiger) wrote :

I found out that there's something missing with xslt rendering enabled: the
value of the CheckBoxField is not interpreted as expected.

Revision history for this message
Eric Casteleijn (thisfred) wrote :

Ok, I'll have a look at that, shouldn't be too hard to fix.

Revision history for this message
Eric Casteleijn (thisfred) wrote :

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.)

Revision history for this message
Wim Boucquaert (wim-boucquaert) wrote :

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.

Revision history for this message
Kit Blake (kitblake) wrote :

This revision:
https://infrae.com/viewvc/SilvaExternalSources/trunk/CodeSource.py?r1=23215&r2=23819
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
field/values.

Revision history for this message
Eric Casteleijn (thisfred) wrote :

What is the error you are getting, if any, or else what is the undesired behaviour?

Revision history for this message
Kit Blake (kitblake) wrote :

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.

Revision history for this message
Eric Casteleijn (thisfred) wrote :

Should be fixed, please test with existing code sources.

Revision history for this message
Benno Luthiger (benno-luthiger) wrote :

I tested with the new Silva 1.6 release and SilvaExternalSources 1.2.
I found only one little problem in SilvaExternalSources/CodeSource._cast_value() (line 73):
===
       if value == '1':
===
This doesn't result in the correct value if the stored checkbox state is 1 (i.e. an integer value). Therefore, I changed this line to:
===
       if value in ['1', 1]:
===
Is there a better way to get the correct value?

Changed in silva:
assignee: wim-boucquaert → aaltepet
Revision history for this message
Andy Altepeter (aaltepet) wrote :

This testing report:
https://bugs.edge.launchpad.net/silva/+bug/101818/comments/8
> 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.

The xslt renderer is OK, but the widgets renderer is still broken.

Changed in silva:
milestone: none → 2.0.5
Revision history for this message
Andy Altepeter (aaltepet) wrote :

---
This testing report: https://bugs.edge.launchpad.net/silva/+bug/101818/comments/8 > 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. The xslt renderer is OK, but the widgets renderer is still broken.
---
This is fixed now. CheckboxFields have the correct values now in both the xslt and widget renderers.

Revision history for this message
Andy Altepeter (aaltepet) wrote :

All bugs mentioned in this issue have been tested and fixed, either previous to 2.0.5, in 2.0.5, or in the next Silva release that packages SilvaExternalSources 1.5.1+.

Regarding the CodeSource bug Benno mentions that requires all lower case field ids, I'm making a separate issue for that.

Changed in silva:
status: In Progress → Fix Committed
Changed in silva:
status: Fix Committed → Fix Released
Revision history for this message
Jon Bowlas (casta) wrote :

After upgrading to Silva 2.1.7 we're getting these errors on all pages containing codesources with CheckBoxFields:

Traceback (innermost last):
  Module ZPublisher.Publish, line 119, in publish
  Module ZPublisher.mapply, line 88, in mapply
  Module ZPublisher.Publish, line 42, in call_object
  Module Products.SilvaExternalSources.CodeSource, line 62, in get_rendered_form_for_editor
  Module Products.SilvaExternalSources.ExternalSource, line 187, in get_rendered_form_for_editor
ValueError: invalid literal for int(): True

Is there an upgrade script available to fix code sources containing checkboxes? I cant see one in the SilvaExternalSources (v2.1.5) product or any documentation re fixing this issue.

Revision history for this message
Andy Altepeter (aaltepet) wrote :

Jon, what version of Silva are you upgrading from? And, with this old version of Silva, is it the case that placing a CS containing a checkboxfield into a new document will yield True/False rather than 1/0 ?

Changed in silva:
status: Fix Released → In Progress
Revision history for this message
Jon Bowlas (casta) wrote : Re: [Bug 101818] Re: Problem with CheckBoxFields as parameters in CodeSources

Hi Andy,

We're upgrading from version 1.5.9 through to 2.1.7.
In version 1.5.9, placing a CS containing checkboxes added the
following XML to the silva document:

<parameter type="string" key="ticker">True</parameter>
or
<parameter type="string" key="ticker">False</parameter>

J

2009/12/31 Andy Altepeter <email address hidden>:
> Jon, what version of Silva are you upgrading from?  And, with this old
> version of Silva, is it the case that placing a CS containing a
> checkboxfield into a new document will yield True/False rather than 1/0
> ?
>
> ** Changed in: silva
>       Status: Fix Released => In Progress
>
> --
> Problem with CheckBoxFields as parameters in CodeSources
> https://bugs.launchpad.net/bugs/101818
> You received this bug notification because you are a direct subscriber
> of the bug.
>
>

Revision history for this message
Sylvain Viollon (thefunny) wrote :

In Silva 3.0, code sources have been revamped. Parameters are no longer stored as string inside the document XML, but as native objects next to it A boolean is therefore a boolean, and this problem no longer exists.

Changed in silva:
milestone: 2.0.5 → 3.0
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.