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

PreferencesHelper does not distinguish defined trait named "*_items" from _items event trait for listeners #225

Closed
kitchoi opened this issue Nov 19, 2020 · 0 comments · Fixed by #226

Comments

@kitchoi
Copy link
Contributor

kitchoi commented Nov 19, 2020

In PreferencesPage, we have this block of code that synchronizes changes on the PreferencesPage with the underlying Preferences:

def _anytrait_changed(self, trait_name, old, new):
"""Static trait change handler.
This is an important override! In the base-class when a trait is
changed the preferences node is updated too. Here, we stop that from
happening and just make a note of what changes have been made. The
preferences node gets updated when the 'apply' method is called.
"""
# If the trait was a list or dict '_items' trait then just treat it as
# if the entire list or dict was changed.
if trait_name.endswith("_items"):
trait_name = trait_name[:-6]
if self._is_preference_trait(trait_name):
self._changed[trait_name] = getattr(self, trait_name)
elif self._is_preference_trait(trait_name):
self._changed[trait_name] = new

#196 makes the PreferencesHelper (the base class of PreferencesPage) consistent in the handling of _items trait: It is assumed to be the event trait for listening to list/dict/set mutations.

This means one cannot have a trait that is actually named *_items and have it synchronized:

class MyPreferencesPage(PreferencesPage):
    name_items = Str()

If this cannot be supported, we should document it and perhaps emit a warning when the trait is skipped.

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

Successfully merging a pull request may close this issue.

1 participant