Hi,

We had created a survey and wanted some message to appear when user clicks on finish button.

Through one of my colleague i came to know about this function — PreSaveAction

function PreSaveAction()
{
alert(“Thanks for the participating in the survey!”);
return true;
}

Placing the above function in the newform.aspx using SharePoint designer  did the trick.

We could use the PreSaveAction function for custom validation as well !

http://edinkapic.blogspot.com/2007/10/add-javascript-date-validation-into.html

Bye..

We developed a web part showing the folders hierarchy using tree view control. However the folders were not getting displayed in the tree view node in the order they are visible inside the document library i.e. sorted on name.

Creating a tree view

http://www.davehunter.co.uk/Blog/Lists/Posts/Post.aspx?List=f0e16a1a-6fa9-4130-bcab-baeb97ccc4ff&ID=115

So finally used the following code to sort the folders

List<SPFolder> folderList = new List<SPFolder>();

foreach (SPFolder myFolder in folder.SubFolders){

folderList.Add(myFolder);

}

folderList.Sort(delegate(SPFolder p1, SPFolder p2) { return p1.Name.CompareTo(p2.Name); });

For more information on sorting

http://www.developerfusion.com/code/5513/sorting-and-searching-using-c-lists/

Bye..

Hi,

I was getting this error while trying to all a new custom web part to the site.

Searching for the same found out the reason for that

It happens when you install smart part

http://www.codeplex.com/smartpart

But haven’t installed asp.net ajax 1.0 version !

http://www.microsoft.com/downloads/details.aspx?FamilyID=ca9d90fa-e8c9-42e3-aa19-08e2c027f5d6&displaylang=en

Follow it with an iis reset !!

Bye ..

Pages that support user customization are known as site pages. E.g. the page that we could see inside our SharePoint designer like default.aspx (home page), NewForm, EditForm,DispForm.aspx etc. The site pages could easily be customized without making any changes to the local file system of the front-end web server and without any need of developer involved for that. This is possible by storing the customized version of the aspx and master page files inside the content database. The saving and retrievig of content from the database is provided using SPVirutalPathProvider class. 

More on SPVirtualPathProvider

http://weblogs.asp.net/scottgu/archive/2005/11/27/431650.aspx

Site pages could exist either in customized(unghosted) or uncustomized(ghosted) state.

For e.g. when we create a new site using one of the default templates, the site as well as pages therin are in uncustomized state i.e. they are based on page templates that live on the file system of the front-end web server. Page template are used for provisioning (creating) page intances. As long as the page is not customized using SharePoint designer or through the Site Settings option the copy of the page is not stored in the content database and the pages are loaded from the file system of the web server. A single page template is compiled into an assembly and loaded into memory of IIS worker process one per web application.

However when page is customized, SPVirtualPathProvider retrieves the customized version of the page from the content database and passes it to ASP.NET parser. Now these pages aren’t compiled into assembly. They are processed by ASP.NET parser in no-compile mode.

No-comiple pages provide higher levels of scalability compared to compiled pages. Compiled pages offer following benefits

·         Performance   Compiled code is much faster than scripting languages such as ECMAScript or VBScript because it is a closer representation to machine code and does not require additional parsing.

·         Security   Compiled code is more difficult to reverse engineer than non-compiled source code because it lacks the readability and abstraction of a high-level language. Additionally, there are obfuscation tools that make compiled code even more resistant to reverse engineering.

However these compiled pages cannot be loaded into memory and unloaded in a manner similar to no-compile pages. .NET framework doesn’t support concept of unloading an assembly DLL from memory. By recycling the current Windows process or AppDomain it is possible to unload the dll, the issues is that it would unload all dll’s from memory, not any specific as desired. And moreover there is limit associated with number of assemblies that could be loaded in a .NET AppDomain.

With no compiled pages there is no requirement of loading assemblies into the memory. Processing for compiled pages is done by loading control trees into memory. Once the processing is finished for a customized page, the page’s control tree is unloaded to free up memory resources. And also as the pages are not compiled, it provides faster response time for pages upon first access.

No Compile Pages enables improved scaling for large sites with 1000s of pages, as windows has limit on number of DLLs loaded into an app and perf degrades as you hit this limit.

Application pages are pages that don’t support customization. They cannot be customized using SharePoint designer. E.g. settings.aspx, create.aspx etc.

These pages are deployed at \Layouts directory of 12 hive and are available to all the sites. They are compiled into a single dll and loaded into memory once per web application. They are used extensively for provisioning and administrating sites as well as elements inside the sites. Application pages links to application.master.

So main differences between these two types of pages could be summarized as  

1)      Site pages support customization whereas application pages don’t.

2)      Site pages once customized run in no-compile mode whereas application pages are always compiled.

3)      Now as site pages support customization it involves risk so under default security policy enforced by WSS we couldn’t write inline code in it  whereas it is allowed to write in-line code in case of application page.

4)      Application page scale better than site page. 

Bye..

Whenever we create a new WSS web application in SharePoint, behind the scene a new IIS Web site gets created. Now to make it SharePoint specific, WSS does the following

• WSS makes few entries into the IIS Metabase. (IIS Metabase stores conifiguration information about it IIS Web Sites and Virtual Directories)
• Creates virtual directories which maps to 12 hive (installation directory\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\)
  • _controltemplates – where user controls are kept.
  • _layouts – has application pages in it.
  • _vti_bin – dlls and web services repository
  • _wpresources – resource file repository for Web Parts
• Adds WSS-specific web.config to the root directory of the IIS Web site.
• Adds wildcard application map to route all incoming to aspnet_isapi.dll. (Right click your iis web site, select home directory, click on Configuration – there we could find the wildcard application map entry.

Finally WSS extends the routing architecture of IIS and ASP.NET to properly route all incoming requests through WSS runtime.

IIS maps an incoming request to a physical file within root directory of an IIS Web Site or virtual directory. (Virtual directory – an entity defining a child URL space nested within the URL space of its parent IIS Web Site. IIS provides the flexibility of defining the root directory for a virtual directory at any location)

IIS supports Internet Server Application Programming Interface (ISAPI) programming model, it allows us to configure an IIS Web Site or virtual directory so that incoming requests trigger the execution of the custom code on the Web Server.

ISAPI programming models consists of ISAPI extension and ISAPI filters.

ISAPI extension is a dll that serves as an endpoint for all the incoming requests.

More on ISAPI extension

http://msdn.microsoft.com/en-us/library/ms525172.aspx

ISAPI filter-acts as an interceptor. It provides pre as well post processing for each and every incoming request. These extensions are however difficult to develop as they are written in C++.

More on ISAPI filters

http://msdn.microsoft.com/en-us/library/ms524610.aspx

For better understanding of low level look at ASP.NET architecture

http://www.west-wind.com/presentations/howaspnetworks/howaspnetworks.asp

In short, ASP.NET framework is implemented as an ISAPI extension named aspnet_isapi.dll. Whenever IIS sees an incoming request targeting a file with extension like .aspx,.ascx,.asmx, based on the application map defined, it forwards the request to aspnet_isapi.dll, which effectively passes control over to ASP.NET framework.

ASP.NET framework compiles an .aspx page to .dll. It parses the .aspx file to generate a C# file that inherits from Page class. Once the ASP.NET page parser builds the source c# file for an .aspx page, it than compile it into a dll. This occurs only the first time when the page is requested; afterwards the same dll is used for all the subsequent requests that target the same page.

Now comes into picture HTTP request pipeline exposed by ASP.NET framework. It provides the developer with a degree of control comparable with ISAPI programming model. Http Request Pipeline contains HttpHandler, HttpApplication nad HttpModule components.

Once a request comes into the AppDomain managed by the ASP.NET runtime, ASP.NET uses the HttpWorkerRequest class to store the request information. Following that, the runtime wraps the request’s information in a class named HttpContext. The HttpContext class includes all the information you’d ever want to know about a request, including references to the current request’s HttpRequest and HttpResponse objects. The runtime produces an instance of HttpApplication (if one is not already available) and then fires a number of application-wide events (such as BeginRequest and AuthenticateRequest). These events are also pumped through any HttpModules attached to the pipeline. Finally, ASP.NET figures out what kind of handler is required to handle the request, creates one, and asks the handler to process the request. After the handler deals with the request, ASP.NET fires a number of post-processing events (like EndRequest) through the HttpApplication object and the HttpModules.

HttpApplication – During the lifetime of a Web application, the HttpApplication objects serve as places to hold application-wide data and handle application-side events.

HttpModules – While the Application object is suitable for handling application-wide events and data on a small scale, sometimes application-wide tasks need a little heavier machinery. HttpModules serve that purpose.ASP.NET includes a number of predefined HttpModules. For example, session state, authentication, and authorization are handled via HttpModules.

HttpHandlers -The last stop a request makes in the pipeline is an HttpHandler. Any class implementing the interface IHttpHandler qualifies as a handler. When a request finally reaches the end of the pipeline, ASP.NET consults the configuration file to see if the particular file extension is mapped to an HttpHandler. If it is, the ASP.NET loads the handler and calls the handler’s IHttpHandler.ProcessRequest method to execute the request.

ASP.NET includes several HTTPHandlers already, including System.Web.UI.Page and System.Web.Services.WebService

http://www.brainbell.com/tutorials/ASP/The_ASP.NET_Pipeline.html

WSS uses the above ASP.NET technique to extend the HTTP Request Pipeline.

Configures each web application with custom HttpApplication object using SPHttpApplication class. This class is within Microsoft.SharePoint.dll. It creates a custom global.asax file at the root of Web Application that inherits from SPHttpApplication.

<%@ Assembly Name=”Microsoft.SharePoint”%><%@ Application Language=”C#” Inherits=”Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication” %>

It also makes use of custom HttpHandler and HttpModule as well.

We could find their entries in web.config of the web applciation

  <httpHandlers>

      <remove verb=“GET,HEAD,POST“ path=“*“ />

      <add verb=“GET,HEAD,POST“ path=“*“ type=“Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c“ />

      <add verb=“OPTIONS,PROPFIND,PUT,LOCK,UNLOCK,MOVE,COPY,GETLIB,PROPPATCH,MKCOL,DELETE,(GETSOURCE),(HEADSOURCE),(POSTSOURCE)“ path=“*“ type=“Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c“ />

// other handlers

    </httpHandlers>

<httpModules>

      <clear />

      <add name=“SPRequest“ type=“Microsoft.SharePoint.ApplicationRuntime.SPRequestModule, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c“ />

// other http modules

    </httpModules>

And finally it makes use of SPVirtualPathProvider, which abstracts the details of where page files are stored away from the ASP.NET runtime, using which the pages are served from content database. Once the content are retrieved by Virtual path provider it is passed to asp.net runtime for parsing. SPRequestModule component contains code to register SPVirutalPathProvider class with ASP.NET framework. SPVirutalPathProvider class works toghether with SPPageParserFilter to supply processing instructions to ASP.NET page parser whether to compile the aspx page to dll or process it in no compile mode.

More on virual path provider

http://weblogs.asp.net/scottgu/archive/2005/11/27/431650.aspx 

Bye..