With MOSS 2007, after inserting a document library web part, you can select a specific view to use for this web part (same for other list web parts).
However I found that once the web part is created, the changes made to that view will not be automatically reflected in the web part. You have to go back to the edit properties window of the web part and re-select the view. It looks like the web part creates a local “instance” of the view definition.
I have a webpart that I want to restrict the access (kind of) by specifying Target Audiences. I created a SharePoint security group (i.e. SP-Group1) which has domain users AND a domain group (say AD-group1) in it. The webpart works for those who were directly added to SP-Group1 but not for those only in AD-group1. So nested group doesn’t work in “Target Audiences”? (I’m pretty sure nested domain groups in SharePoint groups work in permission/login configurations).
Then I tried to specify the domain group AD-group1 directly in that Target Audiences field but it didn’t work. It (and the “Select Audiences” dialog) can not find the domain group at all. It looks like it doesn’t make a trip to domain controller at all!
I also tried to create a new audience in SSP. When I was trying to add a rule saying this audience should contain all members of a domain group AD-group1, that interface can’t find AD-group1 either. Someone said you need to import the profiles from the Active Directory first. This isn’t really nice.
I will try it later since our DC has more than 10,000 users and I don’t want to import everyone to my site. So I will just add everyone to the SharePoint group directly.
To enabled Ajax on your SharePoint site, you have to modify the web.config file as instructed here http://asp.net/AJAX/Documentation/Live/ConfiguringASPNETAJAX.aspx.
The last 2 parts can be skipped if that doesn’t apply to your case.
The good news is that this web.config file can be safely copied over in deployment. Actually it can be used in other sites as a starting point as well. So far the only thing we modified our web.config is to add some SafeControls. So the web.config files aren’t much different from each other anyway. (Update on 12/18: This is not always true. Make sure you don’t have extra entries in the SafeControl list that you haven’t installed on the target server. Otherwise you will see error when you add new webpart)
I successfully add a webpart with UpdatePanel. However the second post back doesn’t seem to trigger? Why?
Excerpt from Mike Ammerlaan’s Blog
Windows SharePoint Services JavaScript has a “form onSubmit wrapper” which is used to override the default form action. This work is put in place to ensure that certain types of URLs, which may contain double byte characters, will fully work across most postback and asynchronous callback scenarios. However, if your scenarios do not involve double byte character URLs, you may successful disable this workaround and gain the ability to use ASP.NET AJAX UpdatePanels.
To do this, you may need to register a client startup script which disables this workaround, in addition to resetting the default form action:
<script type=’text/javascript’>_spOriginalFormAction = document.forms[0].action; _spSuppressFormOnSubmitWrapper=true;</script>
This script may be directly embedded in the page. Or write a function like this:
private void EnsureUpdatePanelFixups()
{
if (this.Page.Form != null)
{
string formOnSubmitAtt = this.Page.Form.Attributes["onsubmit"];
if (formOnSubmitAtt == “return _spFormOnSubmitWrapper();”)
{
this.Page.Form.Attributes["onsubmit"] = “_spFormOnSubmitWrapper();”;
}
}
ScriptManager.RegisterStartupScript(this, typeof(UpdatePanel), “UpdatePanelFixup”, “_spOriginalFormAction = document.forms[0].action; _spSuppressFormOnSubmitWrapper=true;”, true);
}
This solves the second post back problem.
ScriptManager object is required if you want to use AJAX (Microsoft Atlas) in your webpart. In a ASPX page, there should only be one instance of ScriptManager object. However as just a component of a frame work/page, your webpart has no knowledge if the main page (or other web parts) has created the ScriptManager or not. There are 2 options.
One options is to modify the master page to create the ScriptManager object declaratively. Open \12\TEMPLATE\GLOBAL\default.master (or locate it by <site url>/_catalogs/masterpage). Add the following into the markup of your page. A recommended location is right beneath the WebPartManager registration (<WebPartPages:SPWebPartManager id=”m” runat=”Server” />, line 25 in above file):
<asp:ScriptManager runat=”server” ID=”ScriptManager1″ EnablePartialRendering=”True”></asp:ScriptManager>
However, replying on master page to create the object is not very convinient considering deployment and future maintenance. You have to deploy the master page together with your web part, and if there is any design change and new master page is used, you code will break if above script is forgot in the new master page.
So I recommend dynamically create the ScriptManager in your own web part. Then you face 2 issues:
The first issue can be addressed by putting your creation part in a try catch blog - of course you are running risk of ignoring legitimate exceptions. To address the second problem, you can check if there is already such object in the Controls collection. I have a AddScriptManager():
protected void AddScriptManager()
{
try
{
if (Controls.IndexOf(scriptManager) < 0)
{
scriptManager.EnablePartialRendering = true;
Controls.Add(scriptManager);
}
}
catch { }
}
(The scriptManager object is created beforehand.)
If the webpart need to access Sharepoint server info, there are 3 options when deploying the webpart in security context:
In any case, the webpart need to be signed (obviously) and marked as ‘SafeControl’ in web.config file.
If the webpart doesn’t need to access server resource, only need to mark it as SafeControl in web.config and add this line:
[assembly: AllowPartiallyTrustedCallers]
to the source file.
