As you might have guessed already, WSS 3.0 is implemented on top of ASP.NET 2.0. SharePoint Web Applications are nothing more than ASP.NET 2.0 sites with some modifications under the hood. In addition, the new SharePoint web part framework extends the ASP.NET 2.0 web part framework. That offers great flexibility since ASP.NET developers are now even closer to the SharePoint development platform. A large number of posts recommend the use of the ASP.NET WebPart class instead of the WSS WebPart class. Some of them actually suggest that the web part framework in WSS is there just for backwards-compatibility and should be avoided. In my personal opinion, I support the use of the WSS class for SharePoint web parts, and the use of the ASP.NET class for ASP.NET web parts. There is a fuzzy line though between them since the first inherits from the second. I am not totally against ASP.NET web parts in WSS but I believe they should be avoided as your web parts become more sophisticated.
Let us consider the scenario where you need to develop a web part that displays information from your backend system. Probably you will need the same web part in ASP.NET and WSS so I cannot see why the ASP.NET web part framework should not be used. There is no need for any services provided by SharePoint besides the hosting of the web part itself. Now you also have the need for resources such as images, style sheets and other supporting files. This is the point where trouble arises. SharePoint will deploy your web part resources in a special folder called "wpresources" under the root of the web application(s) you have your web parts deployed. This special folder holds all the resource files required by the web parts deployed to the web application. Each assembly gets a dedicated subfolder under the "wpresources" folder containing its own resource files. The name of that subfolder will correspond to the assembly name and in case the same assembly is deployed more than once (different versions in the GAC perhaps) the subfolder name might include version and public key. How will you "calculate" the path to your resources in ASP.NET? I can only wish you luck in that scenario but in the case of the WSS WebPart class, you have a very powerful method called ReplaceTokens. ReplaceTokens accepts one string parameter and returns almost the very same string with the difference that it processes some specific tokens within the parameter and replaces them with SharePoint specific values. For example:
ReplaceTokens("Hello, _LogonUser_") will replace "_LogonUser_" with the username of the current visitor.
Here is a list of other tokens:
That should make your life easier since it can return the resources folder for your web part. Let us move on to the scenario where you also need to create a document library at the site where your web part is loaded and in that document library, you need to save a daily report from your backend system. Thinks start to look grim again for the ASP.NET option since it cannot "talk" to SharePoint directly. You can reference Microsoft.SharePoint.dll or any other required assembly but that will be sacrificing the deploy-outside-SharePoint requirement. In this requirement is apparent that you need to separate your ASP.NET web parts from the WSS web parts.
Another good example to show that the WSS web part framework is not here just for your old web parts will be privilege elevation. You have a web part that does some background operations that require administrative access. You can’t give administrative rights to everyone, so what will you do? You can go down the same path as SharePoint developers used to go in WSS 2.0: impersonate another identity. That sounds great! Solution found! To implement it you will need to call unmanaged API and provide a username and password with credentials. Now I have seen many of this web parts and people have passed passwords through web part properties, in a file on the server or web.config itself. The next concern is exposure of the administrative credentials so you might want to encrypt them in a file and soon you realise you have added more components to your solution than you expected in the first place without even discussing any implications of calling unmanaged API. However, the WSS web part framework comes to the rescue; you can execute code with full rights using this simple code:
SPSecurity.RunWithElevatedPrivileges(delegate()
{
// your elevated code here
});
Again, that is as simple as "ABC" to implement and largely reduces the amount of code you need to write and test, not to mention that this is a more secure option with no credentials needed in the immediate code.
These are few of the benefits and weaknesses of the WSS web part framework over ASP.NET web part framework. Clearly, the WSS framework is not here for backwards compatibility only, but also to provide features specific to SharePoint and development around it.
Let us consider the scenario where you need to develop a web part that displays information from your backend system. Probably you will need the same web part in ASP.NET and WSS so I cannot see why the ASP.NET web part framework should not be used. There is no need for any services provided by SharePoint besides the hosting of the web part itself. Now you also have the need for resources such as images, style sheets and other supporting files. This is the point where trouble arises. SharePoint will deploy your web part resources in a special folder called "wpresources" under the root of the web application(s) you have your web parts deployed. This special folder holds all the resource files required by the web parts deployed to the web application. Each assembly gets a dedicated subfolder under the "wpresources" folder containing its own resource files. The name of that subfolder will correspond to the assembly name and in case the same assembly is deployed more than once (different versions in the GAC perhaps) the subfolder name might include version and public key. How will you "calculate" the path to your resources in ASP.NET? I can only wish you luck in that scenario but in the case of the WSS WebPart class, you have a very powerful method called ReplaceTokens. ReplaceTokens accepts one string parameter and returns almost the very same string with the difference that it processes some specific tokens within the parameter and replaces them with SharePoint specific values. For example:
ReplaceTokens("Hello, _LogonUser_") will replace "_LogonUser_" with the username of the current visitor.
Here is a list of other tokens:
| Token | Value |
| _WPR_ | Gets the base path to Web Part class resources |
| _WPQ_ | Gets a unique identifier for a Web Part |
| _LogonUser_ | Gets the Request.ServerVariables( "LOGON_USER" ) |
| _WPID_ | ID Property |
| _WebLocaleId_ | The LCID of the Web site |
| _WPSRR_ | Gets the server-relative path to Web Part class resources |
That should make your life easier since it can return the resources folder for your web part. Let us move on to the scenario where you also need to create a document library at the site where your web part is loaded and in that document library, you need to save a daily report from your backend system. Thinks start to look grim again for the ASP.NET option since it cannot "talk" to SharePoint directly. You can reference Microsoft.SharePoint.dll or any other required assembly but that will be sacrificing the deploy-outside-SharePoint requirement. In this requirement is apparent that you need to separate your ASP.NET web parts from the WSS web parts.
Another good example to show that the WSS web part framework is not here just for your old web parts will be privilege elevation. You have a web part that does some background operations that require administrative access. You can’t give administrative rights to everyone, so what will you do? You can go down the same path as SharePoint developers used to go in WSS 2.0: impersonate another identity. That sounds great! Solution found! To implement it you will need to call unmanaged API and provide a username and password with credentials. Now I have seen many of this web parts and people have passed passwords through web part properties, in a file on the server or web.config itself. The next concern is exposure of the administrative credentials so you might want to encrypt them in a file and soon you realise you have added more components to your solution than you expected in the first place without even discussing any implications of calling unmanaged API. However, the WSS web part framework comes to the rescue; you can execute code with full rights using this simple code:
SPSecurity.RunWithElevatedPrivileges(delegate()
{
// your elevated code here
});
Again, that is as simple as "ABC" to implement and largely reduces the amount of code you need to write and test, not to mention that this is a more secure option with no credentials needed in the immediate code.
These are few of the benefits and weaknesses of the WSS web part framework over ASP.NET web part framework. Clearly, the WSS framework is not here for backwards compatibility only, but also to provide features specific to SharePoint and development around it.
No comments:
Post a Comment