Today’s article is taken from another real world problem.

One of my MOSS portals hosts a large amount of Business Process documentation as MOSS Publishing Pages. The original MS Word based documentation that these pages sprang from now bears little relation to the most recent guidance in MOSS.

The business want to be able to transform the MOSS Publishing Pages into “MS Word 2003” compatible documents at will. You might have heard of Document Converters, a MOSS feature that converts documents into publishing pages? This requirement was like that, but in reverse, and definitely not available out of the box.

I quickly identified a commercial component that converts HTML mark-up to Rich Text Format documents. This seemed like an ideal path to take. RTF documents are feature rich enough for what was wanted and compatible with a wide variety of tools. RTF is an International Standard format.

This still left the challenge of where to obtain the HTML representing the Publishing Page content. Using the Sharepoint API it’s easy enough to get hold of the mark-up within the fields of any publishing page. That isn’t enough though because the publishing page you see on screen is created from the content, the page layout, the master page, and CSS melded together.

Back in my ASP.NET days I would’ve solved this problem by overriding the Render method of my ASP.NET page. This would give me the very same mark-up that was being sent to the browser. Ideal as that sounds I realised that I’d not seen a single example of anyone tapping into the Render method of a MOSS Publishing Page anywhere! How do you do it?

The only clue I found was on Zac Smith’s website;

http://www.trinkit.co.nz/blog/archive/2007/04/19/guide-to-making-sharepoint-xhtml-compliant.aspx

Zac had overridden the Render method of Master Pages. His requirement was to clean up the Sharepoint mark-up to make it more XHTML compliant. Alas, Zacs solution didn’t suit me because he was using inline code in the master page. Enabling Inline Code opens up a security can of worms that I don’t even want to think about!

As an alternative, I immediately thought of Andrew Connells article on Sharepoint Code Behind pages; http://www.andrewconnell.com/blog/articles/UsingCodeBehindFilesInSharePointSites.aspx

Andrews article deals with the creation of an application page with code behind. It didn’t take much experimentation before I was able to create code behind files for Master Pages, and Page Layouts too. This was just what I wanted.

In the end the Master Page code behind option suited my problem best. I created a custom master page based on the existing custom master page that my portal uses, and added a code behind. Within five minutes I was able to manipulate my Publishing Page mark-up however I liked by overriding Render within the code behind!

After a relatively small amount of fun and games, my Render method looked something like this;

 protected override void Render(HtmlTextWriter writer)   

{

        StringBuilder sb = new StringBuilder();

        StringWriter sw = new StringWriter(sb);

        hWriter = new HtmlTextWriter(sw);

         base.Render(hWriter); //Get the rendered page

         //Write out string to RTF Component HERE

        MyVendor.HtmlToRtf.Converter converter = new MyVendor.HtmlToRtf.Converter();

                string rtfFile = converter.ConvertString(sb.ToString());

         if (rtfFile.Length > 0)

        {

            Response.Buffer = true;

            Response.Clear();

            Response.ContentType = "application/msword";

            Response.Write(rtfFile);

            Response.Flush();

            Response.End();

        }

    }

So there you have it - full control of your rendered mark-up from Sharepoint. This could help you with XHTML Compliance, Document Output, Mobile Device Rendering, and lots of other neat applications that just need imagining!