Microsoft Enterprise Content Management (ECM) Team Blog : Page Layouts

Publishing Sites: Field Controls or Web Parts... That is the Question!

ecmblog — Thu, 09 Oct 2008 07:40:00 GMT

There isn't a week that goes by where I don't get an email asking me this very question. More often than not, its because someone has been using the Content Editor Web Part (CEWP) when they should have been using the Publishing HTML field type. This mistake typically goes unnoticed until a customer needs to roll back to a previous version of a page or when they run a content deployment job. So what goes wrong? Well, the CEWP doesn't store version history, it doesn't participate in any publishing approval workflow and it does store absolute URLs rather than relative URLs. The first problem means you'll have to go to site backups to get access to previous versions of content, the second problem means that users will see updates to the content in the CEWP even if an editor hasn't approved the page for publishing and the third problem means that all your hyperlinks will resolve to the wrong address (e.g. http://staging.adventure-works.com/ vs http://www.adventure-works.com/).

Thankfully, all of these problems can be avoided by using the Publishing HTML field type. I've talked at length with Andrew Connell (MVP) about this and I know it's something he is passionate about so I asked him to write up a guest post to explore the topic.

Ryan Duguid
Technical Product Manager
Microsoft Corp

Andrew Connell on Field Controls and Web Parts

One of the most common problems I see with people developing Publishing sites stems from the lack of understanding in the core differences between Web Parts & Field Controls and when to use them. Many a consultant have dug a deep hole in this area. My goal in this post is to make you aware of the differences to make educated decisions when selecting one over the other.

What follows is a discussion with respect to MOSS 2007 Publishing sites (aka: WCM sites), but all the concepts apply to any Windows SharePoint Services 3.0 based site.

When creating editable content regions on a page layout, enabling content owners to add and manage their own content, developers/designers are presented with two options: field controls or Web Parts. These two options are very different and Publishing site developers should be aware of the differences. The fundamental difference comes down to where the data is stored.

Web Parts
Web Parts come straight from ASP.NET and their data is stored in a personalization store. Microsoft was nice and baked the personalization store into the site collection's content database. Data in a Web Part is stored within the context of the PAGE (i.e.: URL) & the user (which could be the shared user or a specific person). This does allow the content in Web Parts to be uniquely personalized by authenticated users.

In addition, developers and designers can only create Web Part Zones on the page layout. Content owners can then put any Web Part in the zones and any content within them.

Field Controls
Field Controls are much different from Web Parts. They are more like windows into list items. A field control pulls data (in display mode) from a particular column in a list item and writes back to that column in edit mode. Pages in a Publishing site are stored as items in a list; the Pages list. Because they are in a list, they can leverage all the benefits a list has to provide, but visioning & history is the most important here. Just keep one thing in mind: field controls are simply gateways, or windows, to the data.

When a developer places a field control on a page layout, they have the ultimate control of where it is placed on the page and any rules such as if the content owners can insert tables or images into the content. The content owners can only work within the rules defined by the developers.

What is the significance?
Great question! From my experience, MOST customers (90%+) who are rolling out a Publishing site, or Web-based content management systems such as MOSS 2007 WCM, are doing so because the following aspects are important to the project:

Consistent lookand feel (aka: a corporate brand)
Empower content owners & subject matter experts (SME) to maintain the content
Free up IT staff from updating content submitted by SMEs
Structured organization of contentand a versioned and/or historical record of the content

The challenge here is that Web Parts pose a problem with this approach. Because their data is stored in the ASP.NET personalization store in the context of the page (it's URL mind you) & the user. However with field controls, the data is saved with the page's list item. This means that when the page is updated, a new version is created and the old data is retained with the page.

Another challenge is with URLs in the content... especially relative URLs. Take the Publishing HTML field type & the Content Editor Web Part (CEWP). The CEWP does not store relative URLs... it stores only absolute URLs. Even if you enter a relative URL into the editor, it will be converted to an absolute URL. The rich text editor that the Publishing HTML field type is tied to does not convert relative URLs to absolute URLs.

If structure and history is important on your site, you should ONLY consider field controls for your content. If you want to have a more relaxed authoring environment where structure & history isn't important, Web Parts are better. What if structure & history is important... does it ever make sense to use Web Parts? Sure! Use them for providing functionality like stock quotes, consuming news feeds, or rolling up content (as in the Content Query Web Part). In this scenario, the only data that's stored is configuration data... not true content.

To summarize: the content in Web Parts is not versioned and there is no history, but the content in field controls is versioned & a history is retained (provided the Pages library has versioning enabled, which it does by default).

-AC

Andrew Connell
MVP Office SharePoint Server
www.andrewconnell.com/blog
Sr. SharePoint Instructor - Ted Pattison Group
http://www.tedpattison.net/

Building tylerbutler.com, Part 2: Building Content Types and Page Layouts

ecmblog — Mon, 06 Nov 2006 22:27:00 GMT

Part 1 :: Part 2 :: Part 3 :: Part 4 :: Part 5 :: Part 6

This is part 2 of an ongoing series of posts about my experience building a custom site on top of Office SharePoint Server 2007. If you haven't yet read part 1, I'd strongly suggest reading it first.

In my last post, I discussed planning and building out my site structure, as well as customizing my master page. In this post, I'll cover creating page layouts and their backing content types, and customizing the Content Query (CQWP) web part to roll up individual posts into a summary page.

Creating Content Types

The first thing I needed to do before I could go about creating my custom page layouts was create a content type. Because I wanted it to be used by pages in my site, I used the Page content type as the parent for my custom content type, which I called TBPost. I then added a few custom fields to my content type, with the following column types:

Column Name	Column Type
Post Author	Person or Group
Page Content	Publishing HTML
Post Time	Date and Time
Featured Post	Choice
Post Category	Lookup

Most of these custom columns are straightforward, with the exception of the "Featured Post" and "Post Category" fields.

The Featured Post field is used to determine whether a given post is featured on my site. In practice, posts that are featured get displayed at the top of the rollup pages and have a slightly different style applied to them. I have three options for this field: Not Featured, Section Only, and Front Page. By setting this field on a given page, I can make it display at the top of either the front page of the site, or only on the rollup page for a specific section. If a post is set to be featured on the front page, it's implicitly meant to be featured within the section as well. I'll explain how I do this a bit later.

The Post Category field is a lookup field to a custom list that I created that contains all the categories that a post can be in. You may be wondering why I use a lookup field in this case, instead of just a choice field, like I did for the Featured Post field. Well, a given category has an image associated with it, and by using a custom list to store the categories, I can associate an image with each category as an additional column in the list. In the end, I have not been able to leverage this in the way I initially planned, but with this design I do have capability to associate additional data with a category and look it up using code if I need to.

I should also note that both the custom columns and content type I created are in the root site. This is so that the entire site hierarchy can use them, and so that the Content Query web parts can filter on them. But both content types and columns can be scoped to a subweb.

Building Page Layouts

With my new content type created, I set about building my page layouts. I started with the Post layout, which is used by every individual post in the site. Whenever I want to post something new, I simply create a new Page in the appropriate subweb using the Post page layout.

To build the layout, I followed pretty much the same steps that I did when building my master page: I opened up a page on my old site and copied the HTML source for the main post body into the PlaceHolderMain content placeholder in my page layout in SharePoint Designer. Then I removed the content of the post, and dragged in field controls from the handy SharePoint Designer toolbox. Here's what the page layout looks like in SharePoint Designer:

The Post page layout in SharePoint Designer

This whole process was very easy, because SharePoint Designer automatically loads the appropriate fields and controls into the toolbox based on content type that I associated with the page layout when I created it. It really is as easy as dragging and dropping these fields into the right spot on the layout. One other thing I did was add an Edit Mode Panel to the top of the layout. This nifty little thing only displays its contents when the page is brought into edit mode, so it's perfect for controls that you want only your authors to see or edit. In my case, I put the Featured Post and Post Category field controls there. You can find the Edit Mode Panel in the toolbox, under SharePoint Controls -> Server Controls.

The trickiest problem I ran into was how to display the category image for a post. It couldn't be hard coded into the layout, because then I'd need a separate layout for every category, which would be a pain to maintain later. I could also have used an image field control, but then every time I created a new post I would have to select the image. I wanted it to be done automatically based on the category I selected.

My initial plan was to create a custom field control or web part that would render out the right image based on the category I'd selected on the page. However, I really wanted to avoid writing code, so I made a compromising solution. Every site in MOSS has an associated site image. This image is what's displayed in the top left-hand corner of the site when you're using default.master. I changed this for each of my subwebs by going to Site Settings -> Title, description, and icon. Then, in my page layout, I used some markup from default.master to insert that site image into the layout:

<SharePointWebControls:splinkbutton runat="server" NavigateUrl="~site/" id="onetidProjectPropertyTitle">
	<SharePointWebControls:sitelogoimage id="onetidHeadbnnr0" runat="server"/>
</SharePointWebControls:SPLinkButton>

As you can see, the sitelogoimage control is wrapped in a splinkbutton control that points to the subweb, not the site collection. This means that if I click the category image for a given post, I am taken to the subweb that that page is in, which essentially takes me to the rollup page for that category. This is the exact functionality I had on my old site. This solution is pretty elegant, and prevents me from having to use different page layouts on different sites or pick images manually for every post. It's not ideal, however, for reasons I'll point out a bit later.

Rollup Layouts

Now that I had a layout for my individual posts, I wanted to make some layouts for my rollup pages that would aggregate all the pages in various categories, and across the whole site. I started with the individual site rollup page layout, since most of the rollup pages in the site would use this layout. My main home page would be slightly different, but I'll get to that in a minute.

I knew that I wanted to use Content Query web parts for rolling up the pages, so I put a web part zone in the center of my layout and added the web parts to the zone there. I added two web parts. The first CQWP was configured to roll up only pages that were featured on either the home page or the section (using the Featured Post field I mentioned earlier). I did this by configuring the part to look for Pages under the root site that had the content type TBPost. I also used the Filter properties, telling it to exclude pages that did not have their Featured Post property equal to "Front Page" or "Section Only." I also wanted to be sure that my rollup pages were excluded from the CQWP, so I set it to filter out pages whose category was "Rollup."

The second CQWP was configured to roll up all pages across the subweb, i.e. all pages in a given category. To accomplish this, I filtered the results only on the Rollup field and I excluded pages that had their Featured Post property equal to "Front Page" or "Section Only." This means that if a post is featured, it only shows up in one of the CQWPs. I also turned on the RSS feed for this second web part, but I'll discuss RSS at greater length later. Finally, I configured both web parts to only return 5 items apiece.

The other thing I needed to do was tell the CQWP to go and grab some of my extra fields. By default, the CQWP does not return all of the fields for a given page. However, you can override this behavior by setting the CommonViewFields property. There is more information on doing this in George's post on the CQWP. In my case, I set the property as follows:

CommonViewFields="Title,Text;Comments,Text;PostAuthor,User;PostCategory1,Lookup;Post_x0020_Time;"

I also didn't want to have to use the annoying name Post_x0020_Time in my XSL, so I used the DataColumnRenames property to tell the CQWP to remap that field name to another name in my XSL:

DataColumnRenames="Post_x0020_Time,PostDate;"

At this point, my CQWP's were configured to grab the right data, but of course they didn't render the content quite like I wanted them to. In order to get things looking right, I had to edit the XSLT that was being applied to the items, thus changing how they got rendered out. I'll tackle that particular task in my next post. Until next time...

Part 1 :: Part 2 :: Part 3 :: Part 4 :: Part 5 :: Part 6