Publishing sites: field controls or Web Parts... that is the question

[via Enterprise Content Management Team Blog]

This entry is cross posted from my guest blog entry on the Enterprise Content Management Team Blog.

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 (ie: 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 look and 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 content and 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 the Publishing HTML field type is tied to does not convert relative URLs to absolute ones.

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 visioning enabled, which it does by default).

[Updated 10/9/2008 3:30p] A paper I've been working on that touches on this subject was published today on MSDN: Prescriptive Guidance for SharePoint Server 2007 Web Content Management Sites.

Technorati Tags: sharepoint,publishing site,moss,wcm,page layout,field control,web part

posted on Thursday, October 09, 2008 8:34 AM

Feedback

re: Publishing sites: field controls or Web Parts... that is the question 10/9/2008 9:21 AM Bryan Bolling

This is the best explanation I have heard about differences between web parts and field controls. Thanks to Andrew also for pointing out in his WCM class that any content in the CEWP is not versioned.

re: Publishing sites: field controls or Web Parts... that is the question 10/9/2008 9:58 AM Aapo Laakkonen

I think that you generalize too much. What you are talking about is that with OOTB Web Parts things are a little bit like what you mentioned. With your own webparts and user controls (or webparts that can have their display logic written in user controls -> benefits web designers) you can have all the benefits that you have with field controls with additional benefit of reusability and being able to move your web parts around. You can have many different looks for the same web part very easily by using user controls in their display logic (or templeting engine) -> web designers can simply write new ascx:s. Heck, you can even use the same Pages lists and their metadata in your web parts if you like. You can also write forms in you web parts or use SharePoints default edit forms for editing. There isn't any limit on what data web part can display. For example you can use simple item list as a data source for your web part. You can have versioning on that list too... and workflows and approve policy...

# re: Publishing sites: field controls or Web Parts... that is the question 10/9/2008 11:34 AM AC [MVP MOSS]

Aapo-
Point taken, but taking a step back, you can build anything that does anything. The point was that people usually try to decide between the CEWP & the Publishing HTML field control. So is it a general point? You bet... but of course you could build a Web Part (or anything) that versions the content yourself, either in the personlaization store or in a list or some other persistant store.

re: Publishing sites: field controls or Web Parts... that is the question 10/9/2008 12:38 PM Aapo Laakkonen

Okay, then the title is misleading, better would be: CEWP vs. Publishing Field Controls (vs. other solutions). Trying to use OOTB features in everything is clearly not very clever. You should not decide between CEWP and Field Control (unless you have already ranked other options out). You have a lot of more options to be considered too (e.g. business data catalog, web service backed web parts, infopath forms, document conversion, excel services etc.).

# re: Publishing sites: field controls or Web Parts... that is the question 10/9/2008 12:48 PM AC [MVP MOSS]

Aapo-
I disagree about your point "trying to use OOTB features in everything is clearly not very clever." You should always try to use the OOTB stuff before rolling your own solutions.

Obviously I could write up a LOT more cases, but the point of the post was to talk about... well what I talked about: hitting the hottest of the buttons.

re: Publishing sites: field controls or Web Parts... that is the question 10/9/2008 1:23 PM Aapo Laakkonen

"You should always try to use the OOTB stuff before rolling your own solutions"

Obviously, if they fit. What's wrong with rolling your own solutions (reusable solutions that can be your company's advantage vs. other OOTB point and click dudes?)

Writing your own solutions is not that hard and the good thing is that everything is fully under your control and you don't need ugly hacks that you usually need when you hit the limits with OOTB code? With your own solutions you can utilize the full power of the SharePoint as a platform. OOTB features are just a tip in a iceberg.

# re: Publishing sites: field controls or Web Parts... that is the question 10/9/2008 1:36 PM AC [MVP MOSS]

Aapo-
We're on the same page. Always shoot for OOTB as much as possible for a ton of reasons, but there's a reason why the platform is as extensible as it is: for you to extend and customize!

# re: Publishing sites: field controls or Web Parts... that is the question 10/10/2008 10:46 PM Peter Brunone

What Bryan said. I'd heard the bit about CEWP vs. Field Controls when it comes to URLs, but this went much deeper and really gave me the necessary foundation for truly understanding why.

re: Publishing sites: field controls or Web Parts... that is the question 10/12/2008 8:18 PM Trevor

AC - Can you recommend a good blog, book, article, or other resource, online or print, that can help me learn to create custom field controls? I've used the default 'out of the box' field controls, but am interested in learning to create, customize, and implement my own.

Thanks!

# re: Publishing sites: field controls or Web Parts... that is the question 10/13/2008 12:27 AM AC [MVP MOSS]

Trevor-
Chapter 10 in my book (Pro SharePoint 2007 WCM Development... link on the right-hand side of my blog) shows how to do it. There's also a great new article by Wouter in the SDK that goes into a lot of depth: http://msdn.microsoft.com/en-us/library/cc837956.aspx

re: Publishing sites: field controls or Web Parts... that is the question 10/13/2008 3:09 AM Michal Golda

Thank you great explanation.

What about searching. Is content in Web Part crawl?

Thank you.

re: Publishing sites: field controls or Web Parts... that is the question 10/27/2008 12:26 PM MOSSBUDDY

Great stuff Andrew, thank you.
I wanted to know what happens with a CONTENT EDITOR WEBPART in a publishing portal?
Basically the Page would be stored inside the Pages library and would contain a CEWP. Now when the page is modified and the content is changed inside the CEWP, a new version of the page is created, wouldnt the old version contain the CEWP and the text inside it? If not can we use a simple Rich TEXT field for doing the same stuff in a Field control (will it support JSCRIPT also)?

thank you.

# re: Publishing sites: field controls or Web Parts... that is the question 10/27/2008 3:49 PM AC [MVP MOSS]

MOSSBUDDY-
The CEWP does not work as you explain in your comment... his contents are NOT stored with the page. The page does NOT contain a CEWP, it references the WP who's data is stored elsewhere. As my post states, the CEWP has the same limitations as any other WP as exlpained in my post here.

re: Publishing sites: field controls or Web Parts... that is the question 10/31/2008 11:14 AM MOSSBUDDY

Thank you Andrew, your explanation really helps me understand the basics, appreciate it very much.

So related to the Page Field Controls, if we have a Aritcle Page layout (out of the box one) and if the Article Page content is really huge (lets say 500 lines) then is there anyway to introduce Paging in the Page layout itself? i.e. the content page will only display Page controls and the contents that fit in X height and rest all will be carried to the next page. The page will also show the Paging controls, is this possible and how can we do it. Thank you.

re: Publishing sites: field controls or Web Parts... that is the question 10/31/2008 11:53 PM MOSSBUDDY

Thank you Andrew, it is really appreciable that along with Sharing this great content you also keep up to replying all of us. thank you once again.

If you dnt mind i have another question, is there anyway to show Content Query webpart in the DISPLAY mode and show a Rich Text editor Field control in the AUTHORIN mode of a Page, any pointers.

Thank you.

# re: Publishing sites: field controls or Web Parts... that is the question 11/2/2008 8:06 AM AC [MVP MOSS]

MOSSBUDDY - See Edit Mode Panel: http://www.andrewconnell.com/blog/archive/2006/12/23/5535.aspx

re: Publishing sites: field controls or Web Parts... that is the question 11/2/2008 10:38 PM MOSSBUDDY

Thank you Andrew, you ROCK! as always the GURU of WCM.

# re: Publishing sites: field controls or Web Parts... that is the question 11/10/2008 3:17 PM Serve Hermans

Hi Andrew. I have built a large corporate intranet using MOSS. The difficulty I am facing is about customers requesting specific 'collaboration' types of functionality on publishing pages. Take for instance lists of links or contacts. Not entirely unreasonable to add that to a page.
Or even better, a web page that is about corporate standards and they want to add those standards to a document library and display them on the page. So we are talking about page related assets.
You probably can imagine all kinds of example where you would want to mix publishing with collaboration. Now my question is, what would you advise? Use a CBQWP and point that to the document library? Or drag the document library onto the page? A link on the publishing page that points to the doclib (although application pages look different).

# re: Publishing sites: field controls or Web Parts... that is the question 11/10/2008 5:52 PM AC [MVP MOSS]

Serve-
You are putting list Web Parts on the pages... not the document libraries or lists on the pages. These are just windows into those collaboration lists. There's nothing wrong with this option. Hard to recommend a one-size-fits-all solution here.

# re: Publishing sites: field controls or Web Parts... that is the question 11/26/2008 6:25 PM TheKid

Personally I think there are other considerations too....

Most important for me is that FieldControls can be queried using CAML. I use this a lot.

Also, Webparts are basically tables and you end up with tables wrapped in tables, not only is this not accessible but can also be slower to render.

To gain the benefit of webparts they have to be 'configured' for every page, particulary the CBQWP. This is a burden on the site authors and makes creating a page more difficult. This is turn leads to more training and potential inconsistancies. You can export a pre-confirgured webpart, but then you are losing half the functionality.

Using webparts also makes making global changes harder. If you have 200 pages using a CBQWP, all configured the same way, and you need to change the query...that's 200 changes, providing you can identify the pages!

As you say consistency is key on a publishing site. No matter how many projects I have worked on where people initlally wanted 'flexability', by the end of the project they really want 'consistency'.

Webparts are take longer to develop than field controls, which in turn take longer than standard ASP.Net WebControls. Initially I write WebControls, then promote to a field control and finally to a WebPart...as required.

I have been to a number of clients where they have spent a long time writing webparts only to put them directly into a layout. They did this because they were 'taught' to write webparts for SharePoint on thier training courses and were never told they could just use standard ASP.Net controls.

I'm not anti-webparts, I use them all the time, but just right tool for the right job!

--Vince

# re: Publishing sites: field controls or Web Parts... that is the question 11/26/2008 6:58 PM AC [MVP MOSS]

Great points Vince!

re: Publishing sites: field controls or Web Parts... that is the question 1/12/2009 8:47 AM Dean

What is the best way to include javascript in pages on a site with publishing enabled? I have run into several situations where other people have edited the contents of a page and the script I had included got wiped out and i am searching for a way to prevent this from happening.
Thanks
Dean

Post Feedback

Title:
Name:
Email:	(email will not be displayed)
Url:
Comments:
Please add 3 and 5 and type the answer here: Remember Me?

All Comments Are Filtered & Moderated
Unfortunately comment spammers are just too effecient and are constantly dirtying up blogs with irrelevant and unwanted comments trying to improve their standing on search engines. All comments on this blog are moderated. I do not censor comments, but I don't approve comments with vulger language or those soliciting products. Most of the time comments are approved within a few hours of being submitted with the only exception when I'm traveling.

Why are you asking for my email address?
The only reason I'm asking for your email address, which isn't required to submit a comment, is to provide a gravatar if you've created an account for yourself and associated your email address with a small image. If you have a gravatar created for the email address you submit, it will appear next to your comment. Otherwise nothing will appear.

What is a gravatar?
A gravatar is a "globally recognized avatar." You can get more information about gravatars, as well as create your own for free, at www.gravatar.com. You can also view my gravatar here.

This work is licensed under a Creative Commons License
Site design by Heather Solomon.