An often overused and hyper sensitized word in most web application development projects is the term “Client Usability”. A natural offshoot of this is the need/urge for personalization, wherein the end user wants to apply the look and feel of the web application he is currently using to all the websites he can deep link into. This is similar to the Themes feature we get to see in most of the popular social networking and e-mail sites.
HTTP Handler is a new feature offered by ASP.NET. The HTTP handler module acts as an intermediary between the web server and the client. This module can be configured to intercept particular URL signatures and perform actions on them selectively. The common areas where this can be used are –
1. Security – Filter out requests from clients for selected websites.
2. Custom styles and Images – Allow users to define and apply their own styles and images.
3. Logic Pre-processing and Logging – Implementing Logic “on the fly” and providing logging information for the application.
Requirement in "All-In"
The Portal independency is a new feature in the "All-In" which is designed to provide clients the luxury of applying their own custom look and feel to the "All-In" site. Common example for the usage would be a Department X wants to display the top banner and the Logo of the parent site from which the user invokes the "All-In" Application; this would then enable the Department to seamlessly integrate "All-In" (or specific web pages) within its own parent site.
Implementation
Http Handlers implement the System.Web.IHttpHandler interface. Any class that implements the IHttpHandler interface can act as a target for the incoming HTTP requests. The IHttpHandlers requires implementation of 2 methods: ProcessRequest and IsResusable.
ProcessRequest – This is like the Page_Load event of the handler. All the logic for processing the Request and modification of the Response can be included in this method. In other words, this is where all the action takes place.
IsReusable – This property is called to determine whether this instance of the http handler can be reused for fulfilling other requests of the same type. HttpHandlers can return either true or false for this property.
Registering HTTP Handlers in Config Files – The HTTP Handler configuration information tells the ASP.NET runtime the nature of the files for the Handler to intercept. This is maintained in the web.config of the web application. The files listed in this section would be eligible for interception by the custom handler.
We can use
httphandlers>
add path="path" type="namespace.classname, assemblyname" verb="supported http verbs">
/httphandlers>
Note: The start angle brackets for HTML are deliberately missed as they were causing a problem in rendering of the blog text.
In the above XML,
The verb attribute specifies the HTTP verbs supported by the handler. If the handler supports all of the HTTP verbs, simply use "*", otherwise list the supported verbs in a comma separated list. So if your handler supports only HTTP GET and POST, then verb attribute will be "GET, POST".
The path attribute specifies the path or wildcard specification of the files for which this handler will be invoked. For example, if you want your handler to be called only when test.xyz file is requested, then the path attribute will contain "test.xyz"; similarly if you want your handler called for any file having .xyz extension, the path attribute will contain "*.xyz".
The type attribute specifies the actual type of the handler or handler factory in the form of a combination of namespace, class name and assembly name. ASP.NET runtime first searches the assembly DLL in the application's bin directory and then searches in the Global Assembly Cache (GAC).
An interesting aside to Http Handlers is that the ASP.NET runtime uses it for implementing a lot of its own functionality. ASP.NET uses handlers for processing .aspx, .asmx, .soap and other ASP.NET files.
Algorithmic Approach for Portal Independency using Http Handlers:
In "All-In", all the GUI design i.e., the layout of all the ASP.NET Web pages (.aspx) is developed as a part of a well defined architecture. One of the pre-requisites for the implementation is that the end user of the feature should override the existing classes of the stylesheets so as to maintain the consistency and screen logic. The end user is free to change the logo and contents of the styles as per his requirement.
1. The styles would be stored in the Database tables, hence associate a unique style identifier ID (text ID) for each user.
2. The Stylesheet and the images would be stored in the Database and would be retrieved by this unique identifier.
3. Create a Class which implements the IHttpHandlers interface. In case maintaining a Session state within the HTTPHandler is a requirement, then the IRequiresSessionState interface should also be implemented. If a handler requires only Read access to the session data then it should only implement the IReadOnlySessionState interface.
4. Within the ProcessRequest method, the HTTP Handler has access to all the ASP.NET intrinsic objects passed to it in its parameter through the System.Web.HttpContext object. Implementing the ProcessRequest method is simply extracting the HttpResponse object from the context object and then sending some HTML out to the client. Similarly, IsReusable returns true to designate that this handler can be reused for processing the other HTTP requests.
5. In this method retrieve all the associated styles for the particular request identifier and write it to the corresponding HTTP Response. This would result in the styles getting rendered along with the output page HTML.
6. Include Caching of styles in the code so that the same styles are retained in Session as the user navigates through each page of "All-In".
7. In the web.config file, include the signature of the URL for which the HTTP handler would be triggered. Here one could create a custom URL signature like FolderName/Unique Style ID/*.aspx.
8. Make modifications to the Master Page of the application such that in case the request URL contains the style sheet identifier then include logic to create the custom signature URL which would in turn trigger the HTTP Handler.
Conclusion
The feature of Http Handlers gives more control to the developer wherein he can code and plug in his own components into the ASP.NET request processing pipeline. The security feature is simplified to a great extent and the developer no longer has to write complex components in C/C++ and host them in ISAPI filters and extensions to provide custom request handling. Happy Coding.
No comments:
Post a Comment