Fix for two issues in View.include #42
Conversation
izapolsk
commented
Jul 7, 2017
•
izapolsk
commented
- View.include passes incorrect parent to included widgets View.include passes incorrect parent to included widgets #40
- Included widgets aren't available in inherited views inherited views don't see included widgets #41
|
@izapolsk That behaviour is intentional, including is not designed to supplement complex logic inside the class being included. |
|
@izapolsk Actually, it is described in readme, why it is done like that :) |
|
@mfalesni , I apparently missed that in readme. Actually, I even didn't think it was intentionally done because everywhere else in widgetastic widget names are exposed in inherited classes. |
|
I am okay with the inheritance thing, but the parent setting - I believe that needs to be done as a switch. |
|
@mfalesni , awesome. regarding parent setting, it relevant to only included widgets. You pass there view's parent instead of current view. So, current view cannot be accessed by included widgets as a result. |
|
@izapolsk Yep, the including view cannot be accesse currentlyd, there are two main reasons why I did that:
I am not a big fan of having the parent as the including widget, but I don't necessary oppose it, so I believe the |
testing/test_basic_widgets.py
Outdated
| assert isinstance(some_form.input1.parent.parent, type(browser)) | ||
| some_form2 = TestForm6(browser) | ||
| assert isinstance(some_form2.input1.parent.parent, TestForm6) | ||
|
|
There was a problem hiding this comment.
Please also add some widgets into the forms 4 and 6 and assert widget ordering.
|
@izapolsk I commented on the unit test, make sure the build passes and add coverage on the inherited widget including ordering. Could you also please modify the readme to include the mention of use_parent? Rephrase the article that there are two possibilities etc ... |
|
@mfalesni, please check whether this is what you expected to see. |
