Last post Mar 22, 2006 03:34 AM by DMW
Aug 14, 2005 11:56 AM|mwherman2000|LINK
Aug 15, 2005 03:20 AM|Fredrik N|LINK
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.
Aug 15, 2005 07:42 AM|mwherman2000|LINK
Aug 24, 2005 02:52 PM|mharder|LINK
Aug 24, 2005 03:04 PM|mwherman2000|LINK
Nov 10, 2005 04:24 PM|bassham|LINK
Nov 10, 2005 08:33 PM|agarwaen|LINK
Nov 10, 2005 09:28 PM|mwherman2000|LINK
Nov 13, 2005 12:29 AM|garymon|LINK
Nov 14, 2005 06:07 PM|mharder|LINK
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">
<form id="form1" runat="server">
<asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">
<%@ 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:WebPartZone ID="WebPartZone1" runat="server">
<asp:Calendar ID="Calendar1" runat="server"></asp:Calendar>
<asp:WebPartZone ID="WebPartZone2" runat="server">
<asp:Calendar ID="Calendar2" runat="server"></asp:Calendar>
Nov 15, 2005 01:13 PM|garymon|LINK
Dec 15, 2005 07:10 AM|DotNetSqlTut|LINK
Unfortunately I can't make WebParts work in a master page when ContentPlaceHolder is inside a WebPart template:
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?
Dec 16, 2005 02:52 PM|mharder|LINK
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?
Dec 19, 2005 08:31 AM|DotNetSqlTut|LINK
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.
Mar 22, 2006 03:34 AM|DMW|LINK
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.