Actions

Proposals/Page layout plugin type

From Mahara Wiki

< Proposals
Revision as of 17:43, 11 July 2020 by Anitsirk (talk | contribs) (Anitsirk moved page Developer Area/Specifications in Development/Page layout plugin type to Proposals/Page layout plugin type: Shorter navigation, not always technical)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The Page (known as the View in earlier versions) is one of the central pieces of functionality in Mahara. Currently users have a limited ability to customize how the Blocks will be positioned on the page via the "layout" tab; i.e. how many columns of blocks there should be, and how wide they should be. We're currently weighing between two alternative replacements to this system, one which is similar to the existing one but also adds "rows". The other which is a completely dynamic layout using the Javascript Masonry library.

This specification is for the idea of making Page layouts into a new plugin type, so that the row/column layout, the Masonry layout, and other Page layouts can all be implemented and deployed separately.

Basically, a Layout plugin would provide a configurable template for how a user can position the blocks on their Page.

Each layout would need to provide the following:

  • A Page-level layout configuration UI, which will be displayed as a section under the Page's "layout" tab.(For instance, in the current layout, a user can specify how many columns of blocks there will be, and how wide they should be.) This UI may be dynamic; e.g. the columns-and-rows layout will let you dynamically add an arbitrary number of rows with a different number of columns in them.
  • A Block-level layout config UI. This should be compatible with the current drag-and-drop block layout system, as well as providing non-JS fallback. Basically, the "pallet" of block types at the top of the page will be a constant, and the Layout will provide the drag-and-drop area(s) below, based on where blocks are allowed to go in that Layout, and how that Page is configured.
  • Database structures to hold any necessary Page config and Block config data for the layout. (Possibly this could be the same shared table for all of them? A config table? Or a serialized data structure put into a text column?)
  • CSS and JS to do the actual layout. It may be tricky to integrate this with Themes; possibly allow each theme to override the CSS and JS from a given Layout plugin?
    • Or require that all Layouts use the same vocabulary of elements and classnames. But it seems like this would constrain the flexibility of Layouts, which is the whole point of making it into a plugin
  • If a user changes the Layout of their Page, we need the Page to not crash and die. At the least, it should move all the blocks into sensible default positions. Better, would be to somehow store the old positions so that if a user switches Layouts then switches back, all the blocks move back to their previous position.