Deploy a web part to a page during feature activation within a Sandbox Solution

Question

I've been hitting my head against a wall on this one for the last couple of days. I have a pretty simple requirement but I cant see how it can be achieved within a Sandboxed solution. I'm depressed because I think its a critical limitation that will cause me grief in future solutions too.

Here is the scenario.

I have an existing site and I want to be able to activate a feature, and then as part of that activation, drop web parts onto some specific pages. In my case I want to be able to drop it onto the "AllItems.aspx" page of a list, but I'm equally having trouble adding it to the default.aspx home page. I would be happy either way.

Note: I want to be able to activate this on existing site, I dont want to create a new Site Definition.

Here is what I have tried:

1. Feature Receiver: No go. You cant use the SPLimitedWebPartManager class, and the SPWebPartManager class works only within the context of the page where its instantiated. So bascially, you cant do this in code.

2. XML Module: I think this is the most likely path forward, however it seems to always want to provision a file to the site. For example, if I want to add a web part to the home page (default.aspx), then there doesn't seem to be a way to just get a reference to the page, it always wants to overwrite it with a new file. But I dont want to do that, I just want to add a Web Part to the existing page. See my elements XML below, I have tried various combinations of "IgnoreIfAlreadyExists" and removing the Path attribute, and setting it blank.

3. Delegate Control: Not allowed in the sandbox.

4. I actually want to be able to add a web part to the "AllItems.aspx" form of a list, so I also tried to add the web part via the SCHEMA.XML file as described here: Add Web Part through the SCHEMA.XML but this didn't work either. I should be able to do it by more heavily customising the List Definition, but that seems a little over the top and I'm reluctant to do that before ruling out the other options.

So, the only Neat way I can see through it is some sort of "Configuration" page, which then does it via the Web Services. But this is a pain, with the user having "Activate" the feature and then "Activate" again on my configuration page.

Anyway, it may just be that I'm missing something obvious. Been a while between XML fiddling on SharePoint for me, and this is my first Sandbox solution. Really hope someone else has cracked this nut.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="Pages">
    <File Path="" Url="default.aspx">
      <AllUsersWebPart WebPartZoneID="Left" WebPartOrder="1">
        <![CDATA[
              <WebPart xmlns="http://schemas.microsoft.com/WebPart/v2" xmlns:iwp="http://schemas.microsoft.com/WebPart/v2/Image">
                <Assembly>(Assembly), Version=1.0.0.0, Culture=neutral, PublicKeyToken=12baeb5f1600543c</Assembly>
                <TypeName>(Typename)</TypeName>
                <FrameType>None</FrameType>
                <Title>ListAnnouncement</Title>
              </WebPart>
            ]]>
      </AllUsersWebPart>
    </File>
</Module>
</Elements>

Answer 1

Given that the goal is to have no manual steps, I can think of a rather hackish workaround that may work.

Use a <CustomAction Location="ScriptLink" ScriptBlock="..."> to 'auto' add script on pages. In the load event handler added in this script, use the client OM to find out about any new Web Parts to add to the page. Next, to find out what Web Parts to add after a feature is activated, use a feature receiver to write a registration to a 'Web Parts to Add' list. In this list, you could add four columns:

• Page Url
• Web Part Zone
• Zone Index
• Web Part Type

I do have the feeling that this is a bit of a workaround.

Big downsides are the fact that with this setup you have to poll the list for new Web Parts each request, or be smart and add some logic to the load script to disable polling to more than once a day (HTTP Cookie for storage).

As far as I can tell, it'll work in the sandbox though!

Hope it helps,

Wouter van Vugt SharePoint HackMaster, but also build sensible SharePoint software... http://blogs.code-counsel.net/wouter