This is the 4th (and likely final) part of our series on how we built a dynamic page template in SharePoint 2013, enabling content managers to configure a custom grid layout within the page. You can find the previous articles in the series here:
In this article we're going to cover the code which consumes the current page level configuration and renders out the user-configured rows, including the web part zones, which comprise the page.
Firstly, we created a custom Page Layout called "Dynamic Page Template". We then added to that page a custom ASP.Net web control, DynamicWebPartZoneRenderer.cs. The entire page template can be viewed here:
The custom web control can be viewed here:
As established in the previous articles, the page configuration data is stored as a JSON string in a SharePoint field for the current page. For a quick recap, the first action performed by the DynamicWebPartZoneRenderer control is to pull the configuration JSON data out of the page field, and de-serialize into a C# object, of type "PageWebPartZoneConfiguration". This class is essentially a collection of "Row Configurations" each of which represents s single row as configured by the page editor. Each Row has the following available settings (we actually implemented more in the real solution):
So once we have the configuration data de-serialized, we can then loop over each row and dynamically render the User Control associated with the "Layout" property. Some of the configuration for each Layout is hard coded in the HTML, for example the number of columns that exist. Other aspects, such as the margin, padding and background colour, need to be set at run-time. This is done in the Base Control from which each Layout User Control inherits - BaseWebPartZoneLayout.
Each Row Layout User Control inherits from a single base user control called "BaseWebPartZoneLayout". Each User Control is implemented consistently with known conventions. This allows the Base Control to manipulate the layout elements according to the configuration set for the current Row. For example, every Row User Control has an ASP.Net Panel with an ID of pnlRow. We then reference that Panel from the Base Control and configure its background colour, margin and padding according to the applied configuration.
We also implement the "Edit" button from this Base Control. We detect if the page is currently in Edit mode and then render out a link for each Row which enables the logged-in user to open up and manage the settings for each row.
If you recall from the first article in this series (all those months ago...), the first hurdle we had to overcome was whether we could dynamically add Web Part Zones to a page. We now know that this is indeed possible but we never fully explained quite how. The big issue was that every Web Part Zone needs to have a unique ID. It also needs to maintain that ID through page postbacks and reloads. Each Web Part Zone also needed to maintain the same ID even if its parent Row was repositioned within the page. So how did we ensure all of this?
Each Web Part Zone is statically added in to its parent User Control. They are purposely not assigned an ID at this stage as they need to be unique to the whole page. So how do we assign these IDs uniquely and consistently?
After the Layout Control has been loaded and initialised (e.g. Colour, Padding, Margins assigned) we then pass an instance of the User Control (via a handle on the Base Control) into a method called "ConfigureChildWebPartZones". This method also receives the "ID" (GUID) for the current Row.
We then loop over each "Control" inside the User Control recursively hunting for any Web Part Zones. When we find one, we then set its ID to a concatenated string comprising of the literal string "dynamicZone_" plus the row ID, plus the index of the Web Part Zone (i.e. if it's the first Web Part Zone we hit, this will be number 1).
Once this process has finished every Web Part Zone is assigned a unique ID, and one that persists even when the Row is moved around the page. If the Content Author changes the designated Layout configuration then any Web Parts within will potentially move. This is not a big problem however, and can be resolved by the editing user.
Please review the code on Github for a complete picture of the process outlined above.
That brings us to the end of this series. Hopefully it has served to present a number of useful techniques that have been brought together to build a much-used feature on our custom web platform. The customisable row settings detailed in this series are really just a starting point. Any number of other possible settings could be applied further enhancing the options and opportunities to page editors.
We have placed a cut down working version of this solution on Github which can be found here: https://github.com/jstrugnell/SharePointDynamicPageLayouts
If you have any questions or suggestions for other enhancements or improvements please get in touch.
Thanks.
About the author
Head of Development
Your business might need more than just Microsoft packages, and this is where James’s expertise and experience comes to the fore. He is responsible for the custom development of online solutions that increase your productivity, efficiency and collaboration between staff. This includes the development of bespoke software as well as tailoring Microsoft’s suite of products so that your needs are met.
