The PageBuilder concept is pretty awesome. The more I use it, the more I've come to like it. It takes what might normally be developer tasks and puts them into the hands of the content owners.
For a long while, though, I was under the impression that, in order for all pages to benefit from PageBuilder flexibility, the author would have to do double the work by creating not only the content, but a new Page Layout to go with it. Not so, my past, ignorant self, not so at all.
In fact, I learned something that has the potential to turn this notion around significantly. A while back, I was helping to develop the architecture for a rather large and complex site. The site had a consistent look and feel across the board, but had many different business units (hereafter referred to as Bus) that had to be covered. Each BU had its own top and left navigation. Some had additional content under the left nav, some had additional content in a third, right-hand column. The header label had to change for each site, as well as many other changes to the functionality of the page, yet the background, general positioning and functionality for all of these elements stayed pretty consistent.
At first, our team looked at this in a very standard approach. However, in order to cover each subtle variance in the BUs, we were looking at over 100 .aspx files. Ouch. Let me say that again. OUCH.
I'm not against creating more templates when needed, but there had to be a better way. After all, these are things that could change over time and any minor change to a BU would then require a developer to look through lots and lots of similar files. As a developer, that idea bothers me.
So I started playing with PageBuilder on my local development environment and found a neat little trick: You can add template configurations in the workarea with pre-defined querystrings. What this means, is that I could define a layout using a Wireframe (PageBuilder) template, then go to Settings and add that same template but this time with the Page ID as a new Content template.
So let's begin at the beginning.
First, as always, is planning. For this, I plan to manage all of my "templates" via the workarea, which means I need a usable folder structure. As you can see in the image below, I have Content and Pages folders, as is standard for most Ektron configurations, and to that I've added a folder for "Templates" where the Page Layouts to be used as "Content Templates" and Master Layouts for Pages will reside.
Next, I'll show you that I've created a very simple PageBuilder wireframe, added to my Template configuration simply as "PageBuilder Template." Creative name, eh?
Inside the template file, as you can see below, I have quite a few very specific DropZones defined.
And this is what my page looks like in Edit mode. You can see that I not only have some flexible dropzones in the center column, as usual, but I also have dropzones in the left and right, in the header and in the footer (not shown).
Taking a quick peek at the code, I want to show you two more things that make this template a little different.
First, in the center column, there aren't just three DropZones. It also has one each of a ContentBlock and a FormBlock.
These can be used to treat any PageBuilder page created using this template also as a dynamic content template. Which of these controls is activated is driven by a small conditional in codebehind.
Hopefully all of that is pretty straightforward so far. What happens next is I create a new Page Layout using this template. For demonstration purposes, I'm adding a logo to the top left, some embedded HTML in the top center, then in the content area, adding a calculator, image and weather widget to the left, center and right columns, respectively.
All well and good. But where's the magic? Never fear, good people. Note for the moment that I added the image in the center to the top of the three DropZones in the middle. Recall that the ContentBlock and FormBlock controls occurred after that dropzone. Now, I'm going to copy the page path with pageid querystring parameter and create a new template in my workarea.
Note that the Template File field has the PageBuilder wireframe template along with the pageid querystring. Do NOT select the box indicating this is a PageBuilder wireframe. Though the code contains PageBuilder functionality, that is not how we are going to USE the page we've just created. So we leave that unselected.
Add that new template to a Html Content folder in the Content root folder. Once you do, any content in that folder, ignoring aliasing, will have a URL like: /WebForms/PbTemplate.aspx?pageid=565&id=1234.
Note how Ektron is intelligent enough to know when you've added a template with a predefined querystring and uses an '&' instead of assuming it always need to use '?'.
Now when we look at the output of this content, we will see all of our lovely PageBuilder elements as well as the dynamic content below that top center DropZone.
What's truly amazing about this is the level of potential that this provides. To do that, I'm going to have to ask you to use your imagination. At this point, I want you to pretend I'm slowly waving my arms at you and saying "imagination" in a very drawn out and mystical way.
Imagine now that all the content in this page is not using PageBuilder to define its surrounding elements and someone says to you, as the developer, that they want exactly the same layout, but with a metadata-driven list in the right column instead of the weather. Well, under those circumstances, you would probably have to create another .aspx page, write up a user control to pull in items based on metadata somehow dynamically driven by the ID in the querystring, assign that to the appropriate folder in the workarea, then notify the user to start making content.
Using PageBuilder to define those items in what I'll call a semi-static way, however, takes all of that process away from the developer. The author or administrator of the content can simply create a copy of the current page layout, swap widgets, and add the template. No developer intervention required. If they follow up with a further tweak - say, that they want the list in the right pushed down 20px to make it line up with the content body - instead of the developer adding classes and editing CSS, the owner of that layout can simply login and drop a spacer widget onto the page.
Picture now, if you will, having widgets for top navigation, left navigation, and every other piece of custom functionality on your site. Basically everything that is NOT standard content. All of a sudden, microsites become content tasks rather than developer pains and you can spend all that extra time making really cool widgets and extending the functionality of your site instead of catering to dozens of minor requests.
This approach works well with aliasing, content types, and performs like a champ in 8.5. If you're using earlier versions, make sure to keep a close watch on performance as 8.5 introduced some fantastic improvements in PageBuilder.
Going back to that site I mentioned earlier. We were looking at way too many templates. However, because the functionality was generally common between all BUs, we were able to leverage this approach, putting that functionality into widgets and designing each section of the site using PageBuilder, making it easy for the client to add/customize BUs on demand with little to no developer involvement required. Using PageBuilder in the around the primary content body allows the client's content owners to quickly and easily create "templates" which provides the content they create with consistent UI elements that can be changed or adjusted as needed.
This architecture ended up being a great win with the client and they love the flexibility it provides. Let me know what you think in the comments below or on Twitter at http://twitter.com/egandalf.