Comment 6 for bug 1537861

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.