You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The point that widgets are meant to be used as classes should be better explained in the docs, I did not get it at first reading. There is a passage in the docs that says:
"ToscaWidgets 2 creates a new instance of a widget every time it is used in a request. This allows widget and application code to update widget attributes in the natural, pythonic manner, ..."
In the beginning, when trying out TW2, I had been mislead by the words "and application code" to believe that widgets are intended to be used as instances by the application. Because otherwise, if the application works only with classes, and instances are created only internally, then application code cannot benefit from the pythonic way of updating widget attributes, only widget code (overwritten methods) can.
Also, if the application is supposed to work with classes only, we need something like the child_args argument of TW1 for making it easier to do standard things like setting options of SelectionFields dynamically. We discussed that earlier, maybe I can work something out this week.
The text was updated successfully, but these errors were encountered:
@Cito reports in Issue #41:
The point that widgets are meant to be used as classes should be better explained in the docs, I did not get it at first reading. There is a passage in the docs that says:
"ToscaWidgets 2 creates a new instance of a widget every time it is used in a request. This allows widget and application code to update widget attributes in the natural, pythonic manner, ..."
In the beginning, when trying out TW2, I had been mislead by the words "and application code" to believe that widgets are intended to be used as instances by the application. Because otherwise, if the application works only with classes, and instances are created only internally, then application code cannot benefit from the pythonic way of updating widget attributes, only widget code (overwritten methods) can.
Also, if the application is supposed to work with classes only, we need something like the child_args argument of TW1 for making it easier to do standard things like setting options of SelectionFields dynamically. We discussed that earlier, maybe I can work something out this week.
The text was updated successfully, but these errors were encountered: