Several of the pages in Toaster still use plain views to render, when they could be using ToasterTable, e.g. the projects page. Often, these pages also rely on RedirectException to control how their parameters are set: a user visits a page at a page with an empty querystring, and is 302 redirected to a different URL which has the required querystring parameters. (For example, the user visits /toastergui/projects/ but actually ends up at /toastergui/projects/?count=10&orderby=updated%3A-&page=1.) This breaks back button behaviour, as the user has to press "Back" twice to get back to the page they were at before /toastergui/projects/. We need to refactor the views so that: 1. Any pages which could use ToasterTables do use them. 2. Any pages which shouldn't use ToasterTables are fixed so they don't rely on redirects to get their parameters set correctly. This issue is here to cover the initial investigation into the work which is required, as I'm not sure which pages are working correctly, which need to go to ToasterTables, and which use redirects (incorrectly).
As this overlaps with the migration of the "all builds", "all projects" and "project builds" tables, and I was in this code anyway, I did a quick survey of tables which still need to be converted to ToasterTable. These ones all have sorting and/or filters and/or editable columns: 1. build tasks (/build/X/tasks): build -> tasks 2. build bitbake variables (build/X/configvars): build -> Configuration -> Bitbake variables 3. build recipes (/build/X/recipes): build -> Recipes 4. build packages (/build/X/packages): build -> Packages 5. build time (/build/X/buildtime): build -> Time 6. build CPU usage (/build/X/cpuusage): build -> CPU usage 7. build disk I/O (/build/X/diskio): build -> Disk I/O 8. layer recipes (/project/X/layer/Y): project -> Layers -> (click layer name) -> Recipes 9. layer machines (/project/X/layer/Y): project -> Layers -> (click layer name) -> Machines 10. build recipe packages (/build/X/recipe_packages/Y): build -> Recipes -> (click the name of a recipe which produces packages, e.g. perl) -> Packages 11. image packages (/build/X/target/Y): (requires a build which produces images) build -> Images (click an image link) -> Packages included Note that the above tables are relatively straightforward, as they don't have any complicated filters (effectively they toggle the results based on the value of one field). The following tables are simple and may not need conversion, as they don't have editable columns, ordering or filtering: 12. build recipe tasks (/build/X/recipe/Y): build -> Recipes -> (click recipe name) -> Recipe details 13. build recipe build dependencies (build/X/recipe/Y): build -> Recipes -> (click recipe name) -> Build dependencies 14. build recipe reverse build dependencies (/build/X/recipe/Y): build -> Recipes -> (click recipe name) -> Reverse build dependencies 15. build package generated files (/build/X/package/Y): build -> Packages -> (click package name) -> Generated files 16. build package runtime dependencies (/build/X/package/Y): build -> Packages -> (click package name) -> Runtime dependencies And this is a special case: 17. Image directory structure is a table, but it uses a tree display library and should probably be left alone.
Just for completeness sake, the group of 'simple' tables (potentially not needing conversion) has another 3 tables: 17. installed package generated files (/build/X/package/Y): build -> image name -> (click package name) -> Generated files 18. installed package runtime dependencies (/build/X/package/Y): build -> image name -> (click package name) -> Runtime dependencies 19. installed package reverse runtime dependencies (/build/X/package/Y): build -> image name -> (click package name) -> Runtime dependencies
Part of the "UI cleaning" work, so moving to 2.2
Closing, as we have done the assessment; I'll make another issue to track the remaining work to convert tables. Belen will email the mailing list with the work left to do.
I cannot do a scenario since this was only an assessment.