How to dynamically switch PageLayout and MasterPage of SharePoint Publishing page?

两盒软妹~` 提交于 2019-12-02 07:38:42

I think you would be fighting SharePoint if you continue down that route, I fear it would also become something of a support nightmare as it becomes less clear where problems lie, or remembering to make changes in both (or all four!) places when something is updated.

You can have controls appear or hide depending on the editmode of a page so what is shown to the user is totally different but all the code for a page is still in one place.

Investigate the editmodepanel.

<publishingwebcontrols:editmodepanel ID="Editmodepanel1" runat="server">
   <link id="Link2" rel=Stylesheet href="<% $SPUrl:~sitecollection/EditMode.css %>" runat="server" type="text/css" />
</publishingwebcontrols:editmodepanel>

I realise that is not quite what you asked... but I find fighting SharePoint is a losing battle you just have to work with its 'way'.

I once wrote a feature to switch page-layouts depending on different criteria. The difference was, that the page-layout was changed during site-creation, not in view or edit mode. The code to change the page-layout is as follows:

    private void SetPageLayout(SPWeb web, string pageName, string pageLayoutName)
    {
        PageLayout layout = null;
        PublishingPage page = null;
        SPFile pageFile = null;
        bool checkedOut = false;

        try
        {
            PublishingWeb publishWeb = PublishingWeb.GetPublishingWeb(web);
            // verify that the requested pageLayout is available
            foreach (PageLayout pl in publishWeb.GetAvailablePageLayouts())
            {
                if (pl.Name.Equals(pageLayoutName, StringComparison.OrdinalIgnoreCase))
                {
                    layout = pl;
                    break;
                }
            }
            // got my layout
            if (layout != null)
            {
                page = null;
                foreach (PublishingPage pubPage in publishWeb.GetPublishingPages())
                {
                    if (pageName == pubPage.Name)
                    {
                        page = pubPage;
                        break;
                    }
                }
                // got my page
                if (page != null)
                {
                    pageFile = page.ListItem.File;

                    page.CheckOut();
                    checkedOut = true;

                    page.Layout = layout;
                    page.Update();

                    page.CheckIn("changed the page-layout to " + pageLayoutName);
                    checkedOut = false;

                    pageFile.Publish("");
                    // If required, approve the page
                    try
                    {
                        pageFile.Approve(string.Empty);
                    }
                    catch
                    {
                        // Page doesn't need to be approved
                    }
                }
            }
        }

My text was too long for the comment box, so I answer on Aiden as if it is an answer, but my question remains!

Hi Aidan, I see SharePoint as a platform where you can build your solutions on. And I think that the WCM solution built by Microsoft on top of the platform is weak. I know my way is not directly the SharePoint standard way, but the standard way just does not work. Combining edit and display mode leads to (pick your choice): - standard SharePoint publishing sites that all look alike but work ok in edit mode - a site that is very editable but very basic in its appearance - a great looking site in display mode, that is almost impossible to edit We have a lot of clashes between the stylesheets needed in display mode with the MOSS WCM stylesheet. We did write all kinds of compensating stylesheets to get it working, but it is a pain in the ***. It is a major flaw to inject code with styles in your page to make editing possible, this should have done completely outside the page you are editing. In an iframe for example which can be displayed as a floating window on top of the page you are editing. But this is not the case. And then I didn't even mention the issues you have when you have tabs or an accordion control on your page.

We are targeting really interactive web 2.0 sites where a lot of content management must be done. Getting editing mode right in the SharePoint way just does not work.

An optimal editing experience is key. So why not use the masterpage and pagelayout optimized for editing so all editable elements are reachable in a clear and consistent way. But then you still need the display mode. This could be done using a complete separate site that just uses the data produced in SharePoint. This can be an ASP.NET site, or if you want full control over the html MVC could be used. I don't at to go that way, because but has a lot of implications in navigation, security, reuse of controls, use of web parts etc.

I think you get best of both worlds if a masterpage/pagelayout is used that is optimized for editing, and another couple of masterpage/pagelayout is used for display only with a minimal set of code in the pagelayout.

So.. keep the answers coming please!

Surely that would require subclassing Microsoft.SharePoint.Publishing.PublishingLayoutPage and use that to render the contents of the actual PublishingLayoutPage required depending on the "edit mode".

How to get a master page changed...ek.

Trying to bend The SharePoint to your will again? ;)

I feel your pain. I'm using 2 ways to get similar behaviour:

A container control to condionally render parts of pages, I think like you suggested. Initially I needed it to hide parts of the page when some field had a specific value so no html was rendered. See wrapper controls. The control itself is very simple, it needs a [ParseChildren(false)] on its class and the render method does not call the base render if the condition is not met. You can extend this to display en entirely different page to an editor and designer although it would all still live in the same page. I guess you could strip out the part used by the analist and put it in its own usercontrol but thats not very maintainable.

Secondly, the form page, e.g. "/Pages/Forms/EditForm.aspx?ID=1", gives a clean view of all the fields on a publishing page.. no design to get in the way. (I use a control on all page layouts that provides 1 click access to this and the current pages library and shows the content type and page layout used. Quite useful when building WCM sites.)

The definitive answer to this question is now "baked" into a product which we call DualLayout for SharePoint! Our approach solves all your SharePoint WCM design nightmare:

  • Introduce an additional view for the end user, besides the WCM edit and display views
  • Never have clashes between SharePoint styles and your own styles
  • Make lean and mean "view" master pages and page layouts that don't interfer with the WCM master pages and page layouts
  • Make super-light pages for the end-user, remove all SharePoint specific page clutter
  • Improve the performance of the pages because we only have a minimal set of controls to render in the end user view

Check it out at http://www.macaw.nl/Het+Bedrijf/Producten/Macaw+DualLayout+for+SharePoint.aspx, see the blog posts in the blog roll of that page for detailed background information.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!