Can Web Parts be used with Master Pages where the master page is used for high-level layout and customizations?

If so, where does the Web Part Manager need to be instantiated?  e.g. in a Master Page? ...the top-level Master Page? ...in a Content Page?

What is the user experience like in terms of using Web Part Catalogs, dragging and dropping Web Parts between zones, customizing a Web Part?  Where should the zones for these functions be instantiated?

Michael.

I should add the WebPartManager to the MasterPage that is designed to be used on pages where the WebPart feature is going to be used.

Where you should add your Zones depends on the layout of your site. For example, if the Zones should be located at the same position on several pages, you can add them to the MasterPage. If they should be located on different location, add them to the Content page.. The MasterPage is a layout template, to make it easier to change the layout by simply changing one page instead of several pages. So it's up to you, how creates the layout, where you want the zones.

 

Thanks Fredrik,

Do you know of anyone (or a sample) that has actually tried using Web Parts with Master Pages?

Thanks,
Michael.

To answer the original question, using WebParts inside Master Pages and Content Pages is completely tested and supported by Microsoft.

As Fredrik said, where you place the WebPartManager and WebPartZones is completely up to you.  The only major requirement is that the WebPartManager must be placed before any WebPartZones.  If you place the WebPartManager on the Master Page, you can use the ProxyWebPartManager control to define static connections on a Content Page.

Regardless of whether the WebPartZones are placed in the Master Page or the Content Page, all of the user's personalization data will be associated with the Content Page.  This is because WebParts Personalization uses the URL as the personalization key.

-Mike

Thanks for the detailed reply Mike.

Knowing that WebParts Personalization uses the URL of the content page is a key piece of new information (at least for me).

Sounds like while technically "it all works", there's still a lot to (collectively) learn what the actual best practices are/prescriptive guidance is from a design perspective.  Im this regard, it will be most interesting to see how SharePoint "v3" is designed use these features, how it implements skins/themes, etc.

Thanks again,
Michael.

p.s. FYI: The WeFly247 sample choose to place the WebPartManager, zones and parts all in the same content page ...a single data point.

I just figured here would be a good place to post my trials and tribulations with master pages and webparts.  So far, I have been able to get a webpart page working well.  However, when I try to move it to use a master page, Internet Explorer refuses to render any of the style information.  The page still looks great in Firefox, but IE won't display correctly.  I've tried moving the webpart manager from the master to the content page, and putting everything in the master and putting everything in the content page.  No matter what I seem to do, I can't figure out how to get IE to display the page with the styles.  Has anyone else had this problem?

Rick

The following link might be interesting in this thread...

http://jason.diamond.name/weblog/2005/11/09/web-parts-and-master-pages

tell me what do you think about it

I'm the original poster and, a the PDC, had a chance to talk to the WSS PMs who implemented the WSS "v3" rendering model using ASP.NET 2.0.  WSS "v3" uses all of ASP.NET except for Themese (relying on an updated version of the "v2" CSS approach for styling a SharePoint site).

My recollection of the conversation is that WSS "v3" hosts the Web Part Manager in the Master Page and the used several content areas (up to 10).

Web Parts are hosed in the Content Pages.

My next step is to look at WSS "v3" Beta 1 to see exactly what the WSS team chose to do.

Cheers,
Michael Herman
Parallelspace Corporation

I have been trying to get this very thing to work all day. What I have found is that if do something very simple, like the following master page, dragging a web part between 2 zones works great.

<%@ Master Language="C#" AutoEventWireup="true" CodeFile="~/mastertemplates/hbf-layout.master.cs" Inherits="hbf_layout" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >

   <head><title>Test</title></head>

      <body>
                  
         <asp:contentplaceholder id="bodyContent" runat="server"></asp:contentplaceholder>

      </body>

</html>


If in the other hand I do something crazy like add a table to format the page, dragging between zones no longer works. As soon as I begin dragging the web part, the mouse cursor becomes a circle with a slash through it and I can not drop the part in any zones.

<%@ Master Language="C#" AutoEventWireup="true" CodeFile="~/mastertemplates/hbf-layout.master.cs" Inherits="hbf_layout" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >

   <head id="Head1" runat="server"><title>Test</title></head>

      <body>

         <table>

            <tr>

               <td>
                  <asp:contentplaceholder id="bodyContent" runat="server"></asp:contentplaceholder>

               </td>

            </tr>

      </table>

   </body>

</html>

Any ideas why the table breaks drag and drop?

Thank you,
Gary

Having a ContentPlaceHolder inside a table should not break drag/drop.  The following pages work fine for me.  Perhaps the issue is that your MasterPage does not contain a <form runat="server"> tag?

<%@ Master Language="C#" AutoEventWireup="true" CodeFile="MasterPage.master.cs" Inherits="MasterPage" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
        <table>
            <tr>
                <td>
                    <asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">
                    </asp:ContentPlaceHolder>
                </td>
            </tr>
        </table>
    </form>
</body>
</html>

<%@ Page Language="C#" MasterPageFile="~/MasterPage.master" AutoEventWireup="true" CodeFile="Default2.aspx.cs" Inherits="Default2" Title="Untitled Page" %>
<asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server">
    <asp:WebPartManager ID="WebPartManager1" runat="server">
    </asp:WebPartManager>
    <br />
    <asp:WebPartZone ID="WebPartZone1" runat="server">
        <ZoneTemplate>
            <asp:Calendar ID="Calendar1" runat="server"></asp:Calendar>
        </ZoneTemplate>
    </asp:WebPartZone>
    <asp:WebPartZone ID="WebPartZone2" runat="server">
        <ZoneTemplate>
            <asp:Calendar ID="Calendar2" runat="server"></asp:Calendar>
        </ZoneTemplate>
    </asp:WebPartZone>
</asp:Content>

-Mike

Awesome. Thank you. I moved the <form/> tag from my content page to the master page and drag and drop works now.

-Gary

Unfortunately I can't make WebParts work in a master page when ContentPlaceHolder is inside a WebPart template:

<asp:WebPartZone ID="WebPartZone2" runat="server">

<ZoneTemplate>

<asp:contentplaceholder id="Content" runat="server">

</asp:contentplaceholder>

</ZoneTemplate>

</asp:WebPartZone>

Otherwise that would be useful to have a common page layout personalized with web parts where the main contain area would keep updated with different pages.

Does anybody know about a way to implement this?

WebPartZone specifically checks for ContentPlaceHolder controls inside its ZoneTemplate, and adds the controls inside the ContentPlaceHolder as WebParts.  What about this scenario isn't working for you?

-Mike

Apologies. It seems that somehow the content was hidden by personalization. After I reset personalization the content page controls became available. Thanks.

At the same time it's strange that they didn't appear in the web parts catalog. Now I can see all web part controls after closing in the catalog. I wasn't able to see any controls inside contentplaceholder before. It might be due my moving controls here and there. Thank you.

I actually believe that using standard WebParts within .master pages is actually quite badly broken (conceptually), beyond the problem of their state being persisted on a per-page basis by default*, for one simple reason: the use of configurable WebParts requires the user to be authenticated.

To me, there is a big difference between customisation of layout to suit user taste (which is what WebParts are good at) and what users are allowed to see (the role of ASP.NET security).

Sure, in certain cases WebParts will require authorization. Only authorized users should be allowed to configure parts at shared scope, and so on. And it's undoubtedly true that certain WebParts might only be allowed to be displayed to certain users. But for an individual user, how they configure a WebPart's positioning or minimised or closed state is really nothing to do with authorisation. Try explaining to a user that they can choose a different theme without logging in (say by storing the theme in the anonymous profile), but not whether the calendar is in the top right or bottom left corner!

If you place WebParts in a .master, then that .master can only be used satisfactorily within content pages that mandate that the user is authenticated. Note that word mandate is used advisedly here. It's not enough that the user actually is authenticated and is presenting an authentication cookie, say, in the case of forms authentication. If the content page falls under the authorization rule of <allow users="*" /> (i.e. all the public pages including the home page), then the WebParts will display incorrectly (if the user has configured them on another content page where authentication was required).

The core concept of a .master being a location where you can place common content is therefore gone if you place a WebPart on it, as that .master can now only be used in fully authenticated parts of the site. Surely WebParts would therefore be more functional in .master files if they were tied to "anonymous personalisation", say using cookies, rather than only to authentication? 

As it is, I can only imagine using "out of the box" WebParts within a .master file on applications where the entire application would fall under the authorization rule <deny users="?" /> or a more restrictive setting.

Still, fair play to the ASP.NET Team: at least I can always tweak providers and override parts of the system to make them work the way that I want them to.

* See Jason Diamond's blog entry at http://jason.diamond.name/weblog/2005/11/09/web-parts-and-master-pages for the beginnings of a work around for this issue.