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
Similar functionality like widget_names for limiting the visited tabs when reading would be nice also for table rows. For example session.host.get_details visits all rows in the host details table unnecessarily.
The text was updated successfully, but these errors were encountered:
I suspect the main problem here would be API design. Since you can ask for multiple widgets, and each could have their own table, you need ability to specify row from particular table. And then, you could ask for a row, but also limit widgets only to these that do not contain any tables - what should happen then? Also, there are probably cases where you would like to read two or more rows, or maybe a range of rows, or maybe every nth row, or everything except specific rows...
Airgun tables (thanks to widgetastic) already have API to read only specific rows, but entire Airgun was designed around the idea that you interact with page through well-defined entity actions. This "all or nothing" approach to reading is direct result of that design decision, and our inability to read subset of rows from test is consequence of that.
Do you have at least rough estimate of performance gains you expect to see by reading only rows that you actually need? Or are there other reasons you want this ability? I'm afraid providing general solution would mean changing core design of Airgun. As a workaround, we could introduce new action to host entity, one that would return this specific table object - which would allow test to only read data it needs. This goes against framework design, but if expected gains are big enough, we might consider bending the rules a bit.
Similar functionality like widget_names for limiting the visited tabs when reading would be nice also for table rows. For example session.host.get_details visits all rows in the host details table unnecessarily.
The text was updated successfully, but these errors were encountered: