Actions

Difference between revisions of "Proposals/Page layout plugin type"

From Mahara Wiki

< Proposals
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
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 the layout of a page via the "layout" tab; i.e. how many columns it should have, 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.
+
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.
 
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.
Line 7: Line 7:
 
Each layout would need to provide the following:
 
Each layout would need to provide the following:
  
* A UI for the user to configure a Page's layout, if it has any configuration options. (For instance, in the current layout, a user can specify how many columns of blocks there will be, and how wide they should be.) The UI should be displayable as a section in the Page's "layout" tab. It 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 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 UI for specifying where each block goes in the layout. This should be compatible with the current drag-and-drop block layout system, as well as providing non-JS fallback.
+
* 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?)
 
* 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?)

Revision as of 12:57, 22 April 2013

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.