Site Search
Content Tools
Main Content
Multiple Page Asset for MySource Matrix
Summary
This document proposes a new Asset for Mysource Matrix, which will provide a way of maintaining and displaying multiple pages of content, whilst still maintaining control over their functionality. The parent will be able to keep track of the pages it has, providing the ability to print page numbers, tables of contents and a standard format across all pages. Each page will be individually accessible and indexable, as each will have their own web paths, yet their display will always be controlled by the parent asset.
Status: Released
Key: draft -> approved proposal -> scheduled -> in development -> in testing -> complete -> released
Estimated Start Date: Mon, 02 Jan 2006
Estimated End Date: Mon, 02 Jan 2006
Planned Release Version: 3.8.0 RC1
Problem Definition
Currently with pages in Mysource Matrix, content is kept separately, regardless of their relation to one another. If there is a large piece of content concerning one particular issue or subject, Matrix currently provides no concrete way for this content to be displayed as a single unit. Asset Listings can be used, but they provide little control over the pages themselves. Pages still control their own display, meaning that if a pages content is changed, then all other assets in the same tree would have to be edited accordingly, as they are unaware of these changes. If additional assets reside or are placed in the tree in which the Asset Listing Page is listing, any current grouping or connection between the current pages may be lost. Also, with the bodycopies unable to be listed, separate Page Assets have to be used to achieve the desired effect.
With this new asset, the parent asset will retain all control over the pages that reside underneath it. It will Display the content based on a set template or layout, provide interfaces to display or edit the details of each of the children pages, and could potentially expose a number of keywords that will allow each page to appear that they know about each other, such as a table of contents, previous and next page titles etc.
Technical Specification
Multiple Page Asset
A new type of asset will be created, which will act as the control centre for the new functionality. The Multiple Page Asset, will extend the existing Page Asset, and will reside in the CMS package. It will allow the functionality of multiple connected pages, as described above, to be performed in an efficient and logical way.
The Multiple Page Asset will act as a minder of all assets that reside below it, controlling their display, addition and deletion. It will need to be aware of all its children, in order to provide the complex functionality required. Its children will also need their own web paths for purposes of indexing, and also accessing of pages individually. Yet when these pages are accessed, they then must send the request to the parent asset, who will then display them accordingly.
For the additional functionality required of the content assets, as described in the above paragraph, another new asset will need to be created. The “Multiple Page Page” will be created to serve the purpose required. Extending Bodycopy, it will provide the standard Bodycopy interface for editing, allowing multiple divs or tables, and will allow the use of any of the content types residing in the system. This will be explained in more detail below.
For the asset to function correctly, all its pages must be linked underneath it in a structure similar to the following:
|_ Page_1 (multiple_page_page)
|_ Page_2 (multiple_page_page)
|_ Page_3 (multiple_page_page)
|_ ...
|_ Page_N (multiple_page_page)
The Multiple Page Layout Bodycopy would set the template for displaying each of the pages. It would expose a number of keywords that will allow access to various properties of the page. These will include, but are not limited to the following:
- Table of Contents
- Next/Previous Links
- Next/Previous Page Titles
- Page Contents
- Various Details for the Current Page (Title, Page Number, Author etc)
The Multiple Page Asset will have the standard printBody() method exposed, but this will only ever be called when it contains no child pages, and will display an appropriate message. As the actual Multiple Page Asset contains no content, when it is accessed, it will call printFrontendAsset() passing in the appropriate asset for the current URL being accessed. However the actual printing of this asset, and any of the pages underneath it, will be performed by the printPage(&asset) method. When printBody() is called for the Multiple Page, it signifies that the user has accessed the base URI of the Multiple Page Asset. In this case we want to print the first page. To achieve this, printBody() will call another member function, getPageAsset(int pageNumber) which will return a reference to the page object that the passed argument applies to. Once printBody() has this object, it will pass it into printPage(), which will then proceed to output the appropriate content. This functionality could be accomplished simply by parsing a page number to printPage(), and letting it perform the entire process. This is not desired as the children pages, who will be calling this a majority of the time, will be able to pass a reference to themselves in, rather than having to create another instance of the page object.
As stated before, each of the Multiple Page Pages will have its own web path. These paths will correpond to each pages page number. So the first page will have the path of ‘1’, the second page ‘2’, as shown below:
|_ Multiple_Page_Layout (URL: NA)
|_ Page_1 (URL: matrixsite.com/myarticle/1)
|_ Page_2 (URL: matrixsite.com/myarticle/2)
|_ Page_3 (URL: matrixsite.com/myarticle/3)
|_ ...
|_ Page_N (URL: matrixsite.com/myarticle/N)
These web paths will again be controlled by the parent asset, so that any reordering, addition or deletion will not cause any problems with navigation to arise. The main method of the Multiple Page Asset that will control this will be linksUpdated(). This function is called currently whenever links are reordered, changed, added or deleted. By overriding this function, the Multiple Page Asset will be able to ensure that at all times the web paths are sequential, ordered from 1 to N (Where N is the number of pages), and that each path corresponds to the correct place in the page order. This will allow reordering and deletion of assets to be performed in the asset map, without breaking any of the Multiple Page’s functionality.
Multiple Page Page Asset
The Multiple Page Page Asset is in essence a bodycopy with a web path. As described above, it contains all of the standard editing functionality and options of a normal bodycopy, and the user will see very little if any visible difference when dealing with a Multiple Page Page compared to a bodycopy. However, it will have to provide more functionality than a Bodycopy.
Firstly it will have to have a web path. This is essential so that each page is indexed and treated as a separate page. This will require changes to the _ createAdditional() method. Here the asset will need to talk to the parent asset, find out how many pages it currently has underneath it, and set its path accordingly. Calling saveWebPaths() would then ensure the path then applies to the new asset.
As each of these pages will have a web path, they can be individually accessed and displayed. However, as stated above, we require them to be displayed uniformly according to the parent asset. This will be achieved through the Multiple Page Page’s printBody() method, which will be what is called when the URL of the page is accessed. printBody() will find its parent Multiple Page, and will then pass a reference of itself to printPage() method described in detail above. The parent will then take over and display the content appropriately.
All functionality for retrieving the content of the page, such as getRawBodycopyContent(), getKeywords() and getContainers() will be inherited from the Bodycopy Asset. The new asset will have a new method printPage() which will simply call the bodycopy class’s printBody() method in order to print its contents.
As web paths play such a crucial part in the Multiple Page Page’s functionality, problems could arise if a Multiple Page Page had more than one Multiple Page Parent. Take for example the following site, where there are 2 Multiple Pages (shown below), both of which have a number of pages:
|_ Page_1 (web path: 1)
|_ Page_2 (web path: 2)
|_ Page_3 (web path: 3)
|_ Links (web path: 4)
|_ Page_A (web path: 1)
|_ Page_B (web path: 2)
|_ Page_C (web path: 3)
|_ Page_D (web path: 4)
|_ Page_E (web path: 5)
When the second page is written, the author decides that as both pages are of similar content, the Links page that appears at the bottom of the first page, would be perfect for the second page to use. When this page is linked underneath the second page, it gets assigned a new web path of 6, keeping it in line with the parent page’s current structure. So the Links page now has web paths of 4 and 6. Which will work appropriately.
However the author then decides to remove Page 1 from the first Multiple Page Asset. This then causes linksUpdated to be called, as there has to be a reshuffle of the web paths. Page 1 and Page 2 remain the same, but when we come across the Links page, the asset will be faced with a problem. When we retrieve the web paths, there will be 2 entries. Which will be unable to be distinguished from each other. When the lookups are updated, the web paths will be reassigned, and there will undoubtedly be conflicts caused, with atleast one of the Multiple Page’s causing an error, due to duplicate or non-sequential web paths, or no web path at all for a a child page.
It may be possible to look at the overall lookup URLs of each web path, and then determine which to change based on these, but for the initial asset, the Multiple Page Page’s will be exclusively linked.