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. -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1537861 Title: View layout becomes corrupted when changed Status in Mahara: Confirmed Status in Mahara 15.04 series: Triaged Status in Mahara 15.10 series: Triaged Bug description: Version: Mahara 15.04.5 (only encountered on this version, after upgrading from 15.04.4) We have had 2 users (out of over a thousand) have this problem so far, and I've been unable reproduce it or trace a specific cause but we do know the order of events and the outcome: They copy a page from another user Change content or add some new content Attempt to change the layout (say from 3 columns to 2 columns) Something goes wrong while the layout is being changed and the data in the table view_rows_columns no longer matches what's in the view table, and the page won't load anymore. As more users encounter this problem (and I'm assuming they will) I will update this report. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1537861/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~mahara-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
