Open CRImier opened 5 years ago
Pushed the initial implementation to devel
. It does address the "not all views need mixins" problem, but doesn't address the "mixin chain" problem.
Another problem I thought of - how do we handle view errors that occur at any stage? What if a custom view's __init__()
fails? What if a custom view's refresh()
fails? Is it easier to break things with such a setup?
Say, there's a new class based off
Menu
, i.e.MessagesMenu
. Let's imagine it needs a single view function redefined. As it stands now, you need to:BaseListUIElement
s, there are 3 views, but the count will grow, and custom view plugin support will be added after some time)get_views_dict
(or whatever it was called)I have a better idea that requires less code to be written, especially as people want to use their own views:
MessagesMenu
-specific mixin with whatever functions you need redefinedMessagesMenu
definition, assign the mixin class to some internal variableDuring initialization, say, when
get_view_dict
is called, it would get the view dict of the parent class, then child classes of all the relevant views would be constructed using the element-specific mixin. Basically, things like these will no longer be necessary.Problems:
BaseListUIElement
->Menu
->MessagesMenu
, mixins of bothMenu
andMessagesMenu
need to be applied