IntegerField parameter in SilvaExternalSources is passed as unicode

Bug #101764 reported by Josef Meile on 2006-12-15
Affects Status Importance Assigned to Milestone
Sylvain Viollon

Bug Description

I just found that if you create a CodeSource with an Integer parameter, this
won't be pass as an integer; it will be still a unicode string. If you iterating
a variable, which has the integer parameter as the higher limit, then you will
get a nice endless loop, which will cope the CPU of your server to the 100%.

Steps to reproduce:
1) Create a code source with an IntegerField as a parameter. Let's call it IntValue.

2) Then add the following script to the code Source:

Parameter List: IntValue
#Comment this out, then you won't get the endless loop
#IntValue = int(IntValue)
i = 1
while i <= IntValue:
  i += 1

Call the external source in a SilvaDocument, then do a preview and wala, you got
an endless loop.

I tried to see if this bug was already solved in the next version of
SilvaExternalSources (1.1); however, the History.txt file only mentions bug
fixes till version 0.13 and the current version used at the ETH is 0.14. Have
somebody here tested the newest Silva version?

Best regards

Eric Casteleijn (thisfred) wrote :


thanks for the bug report! Basically this is something very unfortunate that
we've know about for some time, but have not been able to solve yet:

The parameters of a code source have to be stored as xml in silva document. When
the document is later viewed, the stored value is retrieved from the xml, but by
then of course it is a string.

When your python script expects an integer but gets a string, strange things,
including excessive recursion can happen.

The ways this can be solved are:

1. create a type system solely for storing code source parameter types in xml
and retrieving them from that xml later. This would be the best solution, but
will be a *lot* of work.

2. disallow any parameter type except those that can be stored and retrieved as
strings unambiguously. (I'll have to look into formulator to see how easy this
would be.) This has the drawback that we would lose the part of formulator that
*does* work here, i.e. the validation, so code source developers would have no
control over what authors would fill in, in any given parameter field.

3. Document much better how codesource parameter types currently (half) work,
i.e.: you can use an integer field, but in your script you'll have to cast from
string to integer before doing anything with the variable. The developer *does*
have the assurance that the string (s)he gets back can be safely cast to an
integer, since the validation ensures that.

For your specific case, 3. also suggests a short term work-around.

Kit Blake (kitblake) wrote :

Demoting this to wish priority, as it's not simple and we would need additional
use cases to merit the investment.

Sylvain Viollon (thefunny) wrote :

In Silva 3.0, a code source that wants an integer gets an integer, a boolean gets a boolean, and a Silva object an Silva object. However it will still be your responsibility to check if the integer you get is greater than 0 .....

Changed in silva:
assignee: nobody → Sylvain Viollon (thefunny)
milestone: none → 3.0
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers