Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Widget value type consistency issue, list/dict vs orm/relations #120

Open
g02Gesanto opened this issue Dec 19, 2015 · 1 comment
Open

Widget value type consistency issue, list/dict vs orm/relations #120

g02Gesanto opened this issue Dec 19, 2015 · 1 comment

Comments

@g02Gesanto
Copy link

It seems that while you can pass sqlalchemy orm objects to widgets as values and have them rendered nicely, if there are validation errors the value is changed to a list of dictionaries. This can cause issues when interacting with the value in the prepare function as well as in validators because accessing dictionary values is different than how you access object properties. Not sure how to handle this but wanted to bring the point up to see if anyone else has noticed this and has any workarounds, or if I am just not doing things correctly.

@g02Gesanto
Copy link
Author

An example is I have a grid layout that is rendering a sqlalchemy relation that is a list of objects and I am trying to sort this list in the prepare function on three keys. When sorting you can use itemgetter or attrgetter depending on if you are sorting a list of dictionaries or list of objects. If I use attrgetter because it is a list of objects and the user submits the form which is rejected as invalid (for what ever reason), now I get an error that it can't sort the list as the list is now a list of dictionaries (as to list of objects when initially rendered in a valid state). I often find I have to have conditionals for all forms to check the data type before accessing properties.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant