Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #1634 (closed defect: invalid)

Opened 12 years ago

Last modified 9 years ago

Inconsistent test on forms.SelectionField

Reported by: alexandre Owned by: anonymous
Priority: normal Milestone: 1.0.x bugfix
Component: TG Widgets Version:
Severity: normal Keywords: single select field
Cc:

Description

The test on line 930 of forms.py return false because the types are different

if option_value == value:

The problem occurs when saving form data to a cherrypy session than retrieving it again.

the code to save value on session is folows:

            cherrypy.session["path"].append({
                "key":self.link,
                "path":path,
                "values":values.copy(),
                "lookup_field":field[0:field.find('_lookup_new')]
            })

after code to retrieve data from session is:

            temp = cherrypy.session["path"].pop()
            data = temp["values"]

the test above (line 930) never return True when type of "option_value" is different from unicode, because type of "option" returns unicode.

The fast way to correct this is enclosing both by unicode function like bellow, but I don't know if it will cause another inconsistence.

if unicode(option_value) == unicode(value):

the code above was used in an attemp to extend the SingleSelect Widget to give it some more options, but I think this error can occurs also in other situations.

Change History

comment:1 follow-up: ↓ 2 Changed 12 years ago by Chris Arndt

It is not clear to me what the relation between your code using cherrypy.session and the SelectionField widget is. Maybe you should provide more code showing what you are trying to do.

Even better would be to discuss this on the mailing list first, before you open a ticket :-)

Maybe you just have to provide both the options list and value as unicode when using the widget?

comment:2 in reply to: ↑ 1 Changed 12 years ago by alexandre

Replying to Chris Arndt:

It is not clear to me what the relation between your code using cherrypy.session and the SelectionField widget is. Maybe you should provide more code showing what you are trying to do.

Well, let me explain my environment: to get more flexibility producing a complex web application, I need to move around some forms, clicking on buttons that open other forms, for search some data, select, and return data to previous form, and to do these actions, i need to save the forms data into a cherrypy user session. So, at code above, when I do an append on session, the "values.copy()" copy all values from form to this dict value "values", by this way I have a stack with values of all forms user has been entered. after when user go back to previously opened forms, I will fill forms with previous data and changing just what is necessary (like a lookup selection). All described above works fine, except the SelectionField?, that when values are restored from session "data = tempvalues?" for some reason the value type as changed from integer to unicode, than, debugging I found that test and got the type difference. I can easily fix it in my inherited widget rewriting that test, if fact, it is what I've done temporarily.

Even better would be to discuss this on the mailing list first, before you open a ticket :-)

yes of course, but i've opened a ticket because it realy seems to be a bug and can ocurr in other ways.

Maybe you just have to provide both the options list and value as unicode when using the widget?

Maybe yes, at moment i get value directly from a database field through a SQLAlchemy object, as the widget should be quite generic, I do not know exactly what kind of data is coming from the database, in my particular case specifying the datatype would be a solution, but perhaps not the best.

comment:3 Changed 12 years ago by Chris Arndt

Again, please provide more code showing what you are trying to (preferably on the mailing list).

comment:4 Changed 11 years ago by Chris Arndt

  • Status changed from new to closed
  • Resolution set to invalid

This ticket has not received any feedback/clarification for over half a year. Closing it as invalid.

If the issue still exists and you can provide more information to reproduce it, feel free to re-open the ticket.

comment:5 Changed 9 years ago by chrisz

  • Milestone changed from __unclassified__ to 1.0.x bugfix
Note: See TracTickets for help on using tickets.