Proposals/Multipage Views
From Mahara Wiki
< Proposals
http://wiki.mahara.org/Developer_Area/Specifications_in_Development/Multipage_Views_Take_2 Please visit Multipage Views Take Two after reading this document, it contains the updated specification
Preamble
Being able to group views together into mini "websites" is an oft-requested feature in Mahara. Not only does it provide a way for users to layout their content in a more comprehensive way for larger views, but it also enables them to add access at the "website" level without having to duplicate it across many different views of related content.
New Terminology
Site
We will introduce a new top-level item, which will be called "Site". A site is a list of views (which may be renamed to "Page"), together with some structured navigation, which can include a nested hierarchy.
Implementation Notes
Views can be in more than one website. Access can still be given on the View level, even if a View is in one or more websites. We will have a new (optional) URL parameter "site" for view/view.php, and if it is present, access will be checked on the site level, not the View level.
Some viewtypes are not able to be put into a website (for example profile views) - since viewtypes are not pluggable, this will just be maintained in a static final data structure on the View class.
Nesting navigational structure is able to be defined, but this has no semantic meaning other than for organisational purposes.
User Interface
Adding/Editing Sites
We will introduce a new second level navigation item, "My Sites" under "My Portfolio". On this page will be listed the current Sites the user has, with controls to add, delete, edit details edit, edit access. The page will be very similar to the My Views page.
The Edit Details screen will include the name, description and tags. It will look extremely similar to the Add/Edit View Details screen.
The Edit screen will allow the user to pick which Views make up the site, arrange their navigational structure, and "bless" one as the Default Page (similar to index.html in a website), which will be displayed by default when someone views the Site.
The Edit Access screen will be almost identical to the Edit View Access screen.
Changes to My Views
There will be no changes to My Views, except a banner at the top of the access screen explaining that any Site access will override the View access when the View is being looked at independent of whatever site(s) it is in.
Displaying My Sites
We will write a new blocktype, "My Sites" which will be very similar to the "My Views" block, and can be placed on the profile View.
In-Site Nagivation
We have two different options for how to deal with Site navigation while looking at a View in the site:
This would be added manually to any Views by the View owner, and would display something different, depending on what context the View is viewed in. The block would have no config of its own, it would just read the navigation information attached to the Site that the View is in. The benefit of this approach is that it gives the user more control, and it can be placed wherever they want in the view. The downside is that it looks different in every context, and will be hidden completely sometimes for Views that have access in their own right. There is no smart way to display a preview of this block in edit mode.
The benefit of this approach is that it's much simpler to implement, and less confusing for the View owner. The downside is that it's less flexible, and might be hard to layout in a way that isn't too obtrusive. We could use the strip along the top, but horozontal space is not necessarily very good for tree-style navigation. We could use tabs and subtabs, similar to the Mahara navigation itself, but that too might not scale for views with many pages. We could also do it in a block-style tree approach. One option is to give the user a config option (on the Edit Site page probably) which of these three approaches they want, but this is a lot more work.
Technical Implementation
We will create new tables, site_access*, identical to the view_access* tables, but to hold site access.
There will also need to be:
site
The site table will contain id, owner, ownerformat, title, description, group, institution, startdate, stopdate, ctime, atime, mtime and submittedgroup just as in the view table.
site_tag
The site tag will just be the same as the other _tag tables.
site_structure
This table holds the list of Views that make up the Site, with hierarchy information and a flag as to which is the default View. It probably makes sense to materialise the path for a nested structure (like 1/6/7) so we can retrieve information in the correct order without having to order it in php. When editing the structure, it is simplest to empty and repopulate this table so that the records can be inserted in the correct order.
Outstanding questions and statements
Site and Institution Views
This structure will work well for creating sites out of user views. There is no reason it shouldn't work in a very similar way for group views, but at this time it doesn't make sense to implement for site views or institution views, as they're only being used for templates. Once we build support for creating Site Views to be used for CMS-style functionality, it will make sense to implement this there as well. This is out of scope for this specification.
View Copying
The subject of copying sites hasn't been yet discussed. It could be implemented but is out of scope of this specification
LEAP2A support
A discussion is underway with the LEAP2A community about this but we suspect this will be an extension of a selection, perhaps with some Mahara LEAP2A extensions.
