I’ve been playing around with an idea for a little while, one which I’m not actually 100% sold on yet, but I figured I would put it out there. It has to do with Site Studio templates and how one might go about deploying abstracted, consistent HTML across all templates in a site. Ideally what I’m really looking for is template inheritance, something to allow me to create a base template that I can then build other templates from and on top of. Unfortunately Site Studio doesn’t really provide that kind of functionality, or at least does not have a method described to support it.
The current process for template development goes something like this: Designers take their HTML and paste it in to a new Site Studio layout template, contributor areas are identified and regions/elements are added. Functional areas of the page are broken out in to fragment controls. It’s a fairly organic way of developing a web page, one which makes sense and is easy to understand by most everyone. The problem for me though is that as multiple templates are added to the site, they usually employ a common structure and design of which usually a significant portion ends up having to be duplicated on each template.
A big deal? It’s certainly not the end of the world, but perhaps there’s a more elegant method.
I’ve been tinkering with using fragments or more specifically fragment snippets a little differently then they are more commonly used right now. Instead of pasting in the HTML directly in to the layout template like I normal, I start by creating a new “base layout” and in it I created a series of drop point, reference snippets for each of the opening and closing tags used in the structural formatting for the page.
As you can see from the table above, the fragment holds seven snippets which house the foundational structure of the template and could be re-used on every page in the site.
With the base layout fragment complete, I then created a sub layout which could be used inside the base layout’s structure. Again nothing to fancy, it’s basically a div that contains a place to put a title and some content.
This fragment, which I am calling a container fragment, also allows for an ID attribute for the container’s div to be passed in. This is cool because when I added the fragment to the page I did it three times; twice next to each other in between the “Start of Body” and above “Body Divider” snippets and then once after the “Body Divider” snippet. Using CSS I set the two upper container fragments to float side by side and lower one to take up the entire lower portion of the page.
So just to recap, I created two fragments both of which contain only HTML, added them to the page 4 times(1base fragment 3 container fragments) and interspersed the container fragments in beween snippets from the layout fragment. Looking at the template in design view, you would see that the only HTML present is the HTML,HEAD and BODY tags that the designer adds. All HTML has been abstracted from the template.
From there I added a region to the page, wrapping it’s open and closing region tags before and after the “Start of Main” and “End of Main” snippets. With the region in place, I then went and added elements in between the various snippets. Between the “Start of Title” and “End of Title” snippets(both in the containers and on the page) I added text elements. In side the container, after the “End of Title” snippets, I added WYSIWYG areas. More traditional functional fragments like static lists or navigation could also be placed in between the layout or container snippets also.
Once the region is in, content can be assigned and the layout template can be used to render pages. Instead of having 5-10 similar templates with similar HTML though, with this design all HTML is added once and then can be re-used multiple times. All pages should display in a consistent format and global changes can be made to the design of all pages from a single location.
So what’s the downside? Well there might be a performance impact, it’s just not completely clear if it’s negligible or at what point it will become noticeable. Fragment snippets are really just nodes in an XML file which are rendered using a XPATH expression and Site Studio’s ssIncludeXML IDOC function. The couple fragments I’ve used in my example probably aren’t going to cause a problem, but using this design has the potential to add a great many more snippets to a template then one would normally see. How many is too many, I’m just not sure yet….so far it doesn’t seem to be a problem though.
I’m going to keep evaluating this design and will have some follow up posts down the road. If anyone has any similar stories, post a comment or send me an email, I’d be very interested to hear your thoughts.
