In belated response to your question about why there are so many tables to track view layouts, we do have a couple that could be consider unnecessary if everything was redesigned, but on the whole it's actually a fairly logical mapping of the flexibility of our page layout engine into a relational database:
1. view_layout_columns: A "column layout", i.e. a number of columns, and what page-width each one has. (1 column, 2 columns 50/50, 2 columns 67/33, etc). These are hard-coded.
2. view_layout: Each record is a view layout (i.e. a combination of rows and columns). This includes the 34 hard-coded view layouts that ship with Mahara, and any custom layouts users have produced (if my math is correct, with 1 to 5 rows and 12 different column layouts, there are 12^5 + 12^4 + ... + 12 = 271,452 possible layouts)
3. view_layout_rows_columns: Each record represents one row in a view layout. It indicates which row number it is, and which of the column layouts it uses.
4. usr_custom_layout: Each record is one custom layout generated by a user (or group or institution). This table is used to "bookmark" previously used custom layouts for the user.
If I was rewriting it from scratch, I would probably rename some of the tables to make things clearer. The relationship between view_layout, view_layout_columns, and view_layout_rows_columns is not really made clear by the table names or their column names.
Also, since we've currently hard-coded the views to a maximum of 5 rows, it could also make sense to eliminate the view_layout_rows_columns table, and instead give view_layout 5 fields called "row1layout", "row2layout", etc. And from there, you could also eliminate the "view_layout_columns" table, which describes the column layout with strings like "33,33,33", and just move those strings directly into view_layout.row1layout, view_layout.row2layout, etc.
But, at this point it's probably not worth all the refactoring that would require.
Hi Matt,
In belated response to your question about why there are so many tables to track view layouts, we do have a couple that could be consider unnecessary if everything was redesigned, but on the whole it's actually a fairly logical mapping of the flexibility of our page layout engine into a relational database:
1. view_layout_ columns: A "column layout", i.e. a number of columns, and what page-width each one has. (1 column, 2 columns 50/50, 2 columns 67/33, etc). These are hard-coded.
2. view_layout: Each record is a view layout (i.e. a combination of rows and columns). This includes the 34 hard-coded view layouts that ship with Mahara, and any custom layouts users have produced (if my math is correct, with 1 to 5 rows and 12 different column layouts, there are 12^5 + 12^4 + ... + 12 = 271,452 possible layouts)
3. view_layout_ rows_columns: Each record represents one row in a view layout. It indicates which row number it is, and which of the column layouts it uses.
4. usr_custom_layout: Each record is one custom layout generated by a user (or group or institution). This table is used to "bookmark" previously used custom layouts for the user.
If I was rewriting it from scratch, I would probably rename some of the tables to make things clearer. The relationship between view_layout, view_layout_ columns, and view_layout_ rows_columns is not really made clear by the table names or their column names.
Also, since we've currently hard-coded the views to a maximum of 5 rows, it could also make sense to eliminate the view_layout_ rows_columns table, and instead give view_layout 5 fields called "row1layout", "row2layout", etc. And from there, you could also eliminate the "view_layout_ columns" table, which describes the column layout with strings like "33,33,33", and just move those strings directly into view_layout. row1layout, view_layout. row2layout, etc.
But, at this point it's probably not worth all the refactoring that would require.