HTTP Handlers - Places where can be used

An HTTP Handler is a .NET class that executes whenever you make a request for a file at a certain path. Each type of resource that you can request from an ASP.NET application has a corresponding handler.

For example, when you request an ASP.NET page, the Page class executes. The Page class is actually an HTTP Handler because it implements the IHttpHandler interface.

 

·         Other examples of HTTP Handlers are the TRaceHandler class, which displays application-level trace information when you request the trace.axd page, and the

·         ForbiddenHandler class, which displays an Access Forbidden message when you attempt to request source code files from the browser.

·         You can implement your own HTTP handlers.

o    For example, imagine that you want to store all your images in a database table. However, you want use normal HTML <img> tags to display images in your web pages. In that case, you can map any file that has a .gif or .jpeg extension to a custom Image Http Handler.

o    The image HTTP handler can retrieve images from a database automatically whenever an image request is made.

 

·         Or,Imagine that you want to expose an RSS feed from your website. In that case, you can create a RSS HTTP Handler that displays a list of blog entries or articles hosted on your website.

 

 

You can create an HTTP Handler in two ways. You can either create something called a Generic Handler or you can implement the IHttpHandler interface in a custom class. This section explores both methods of creating an HTTP Handler.

 

 

Thanks & Regards,

Arun Manglick

SMTS || Microsoft Technology Practice || Bridgestone - Tyre Link || Persistent Systems || 3023-6258

 

DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.

Attributes to consider applying when writing a web custom control

Attributes to consider applying when writing a web custom control

Almost every custom control has at least one additional public property, and that public property as well as the control itself should probably have at least a few attributes applied to them.  Attributes tell the designer host (Visual Studio) or the parser (ASP.NET) interesting things about your control that might not be evident from just its name and its type.

Came across an interesting link that gives a quick overview of some of the useful and important attributes that you can apply to your control and its properties and events.

Following are some of the extracts from the same -

By applying the proper set of attributes you can significantly increase the usefulness of your control in several ways. For example, the DescriptionAttribute provides helpful text to the person designing the page. The ValidationPropertyAttribute is required when the person designing the page wants to validate the value of your control. Following is a list of the most useful and important attributes you can apply to your control and its properties and events.

Control attributes:

• ControlValueProperty
   - Used by data source parameters to get the "intrinsic" value of the control. For example, DropDownList's "intrinsic" value is its SelectedValue property.
• DefaultEvent
   - Set the event for which to create an event handler when double clicking the control in the designer.
• DefaultProperty
   - Set the default selected property in the designer's property grid.
• NonVisualControl
   - Hide the control at design time when "Non Visual Controls" is unchecked from the View menu.
• ParseChildren
   - The full name is really "parse children as properties".
   - Set to true if the inner contents of the control represent properties as opposed to child controls.
   - True by default on controls deriving from WebControl; false by default otherwise.
• PersistChildren
   - The full name is really "persist child controls".
   - Set to true if the designer should persist child controls as the inner contents.
   - False by default on controls deriving from WebControl; true by default otherwise.
   - 99.9% of the time PersistChildren has the opposite value of ParseChildren.
• ValidationProperty
   - Required when a control can be validated.
   - Somewhat similar to the ControlValueProperty in that they often point at the same property.
• ViewStateModeById
   - Indicates that viewstate should be loaded based on control IDs as opposed to being loaded based on the index of the control in the child controls collection.

Property attributes:

• Bindable
   - Indicates at design time only whether the property should appear by default in the Edit Databindings dialog.
• Browsable
   - Get-only property: Always false.
   - Get/Set property: Whatever you want.
• Category
   - Determines in which category the property will appear when the property grid is in category mode.
• DefaultValue
   - Get-only property: Since you have Browsable(false), and it's never persisted anyway, no default value is needed.
   - Get/Set value type property: Must be set.
   - Get/Set reference type property: Must be null so that it shows up as non-bold in the property grid.
• Description
   - Determines the help text that will show in the property grid's lower help panel.
• DesignerSerializationVisibility
   - Controls whether the property is persisted in the markup (see also PersistenceMode).
   - Use this to prevent get/set properties from being persisted at all.
• PersistenceMode
   - Controls how the property is persisted in the markup.
   - Simple-valued properties should use the default, which is Attribute.
   - Collection, template, and complex (e.g. styles) should use InnerProperty.
   - InnerDefaultProperty should never be used since it causes compatibility problems. For example, if in the next version of your control you want another inner property, it won't work properly.
   - EncodedInnerDefaultProperty should also rarely be used for similar reasons as InnerDefaultProperty.
   - In ASP.NET 2.0 support was added for strings to be InnerProperties, which is good for large multi-line string values, such as XmlDataSource's Data property.

Event attributes:

• Browsable
   - Same as properties.
• Category
   - Same as properties.

Please note that the above is only a part of the complete list.
For details check out the link :

http://weblogs.asp.net/leftslipper/archive/2007/02/15/attributes-to-consider-applying-when-writing-a-custom-control.aspx

 

 

Thanks & Regards,

Arun Manglick

SMTS || Microsoft Technology Practice || Bridgestone - Tyre Link || Persistent Systems || 3023-6258

 

DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.

Prefetch Pages through AJAX

 

Following approaches have been thought of:

 

1.     Currently I have implemented this by using frames in which I have two frames, one frame has current page and other has the prefetched page and this frame is hidden. On demand of this page the frame is mad visible and next page is prefetched in other frame and that frame is made hidden. Currently this approach is working fine but still I would like to have your comments on this approach. Like are there any unseen issues in this method, is this an acceptable approach or not?

2.     Second approach thought by me for the same problem is loading the next page asynchronously through AJAX call and storing its rendered HTML. On demand of this page the rendered HTML is pasted in current frames page. Problem viewed in this approach is that server event does not get fired and JavaScript specific to the page are not rendered. Can you please suggest some solution for the problems stated? Also prefetching the whole page asynchronously, is it a good idea? This question arises because AJAX is mostly used to fetch parts of data on the page asynchronously.

3.     Next approach is to prefetch the data on the page and populate the HTML DOM on demand. But if we are prefetching the page data then we should maintain it in a format readable on client side say XML. This seems to be a convincing option but can this approach be made generic from implementation point of view?

4.     Last approach suggested by you is using Multiview control wrapped in an Update Panel. Will this approach load data for each view asynchronously or at first time it will load data for all the views?

These are possible solution for the problem. Can you please comment and suggest the best of the all? Also, if you have some other solution for the same can you please let me know that too?

 

 

Thanks & Regards,

Arun Manglick

SMTS || Microsoft Technology Practice || Bridgestone - Tyre Link || Persistent Systems || 3023-6258

 

DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.

GridView Styling [.Net 2.0]

Problem:  I need to have many GridView control used all over my Application and need to ensure standard look and feel across all of them.

Solution:  Use the default style templates provided out of box. This is a good way to have standard look and feel, but adds a lot of code in your aspx page which is hard to manage and looks dirty. It becomes cumbersome if the client later makes a comment saying “I do not want Blue Headers, make it Black!” you would need to change every possible GridView in your application.

A more elegant way of achieving the same would be to have your own CSS file which could be used by all the GridView across your application. Below is a sample CSS file that I often use/re-use for GridView controls

File: GridView.css

.gridView{

       width:100%;

       padding:4px;

       color:#333333;

       border:none;

}

.gridView td{}

.gridViewHeaderStyle{

       background-color:Silver;

       color:Black;

       font-weight:bold;

}

.gridViewFooterStyle{

       background-color:Silver;

       color:Black;

       font-weight:bold;

}

.gridViewRowStyle{

       background-color:#F7F6F3;

       color:#333333;

}

.gridViewAlternatingRowStyle{

       background-color:White;

       color:#404040;

}

.gridViewEditRowStyle{

       background-color:#999999;

}

.gridViewSelectedRowStyle{

       background-color:#E2DED6;

       color:#333333;

       font-weight:bold;

}

.gridViewPagerStyle{

       background-color:#284775;

       color:White;

}

.gridViewEmptyDataRowStyle{

       background-color:#FFC0C0;

       border-color:Maroon;

       border-width:1px;

       border-style:solid;

       font-weight:bold;

       vertical-align:middle;

}

Now where ever your have to place a GridView control, include this file in the page and refer the CSS clases at right places. Below is one such snippet of same:

<asp:GridView id="gridViewMessageList" Runat="server" GridLines="None" CssClass="gridView">

    <FooterStyle CssClass="gridViewFooterStyle"></FooterStyle>

    <RowStyle CssClass="gridViewRowStyle"></RowStyle>

    <EditRowStyle CssClass="gridViewEditRowStyle"></EditRowStyle>

    <SelectedRowStyle CssClass="gridViewSelectedRowStyle"></SelectedRowStyle>

    <PagerStyle CssClass="gridViewPagerStyle"></PagerStyle>

    <HeaderStyle CssClass="gridViewHeaderStyle"></HeaderStyle>

    <AlternatingRowStyle CssClass="gridViewAlternatingRowStyle"></AlternatingRowStyle>

</asp:GridView>   

 

Benefits:

1.     Maintenance is directly proportional to clarity and size of the code you write.

2.     Avoids repeatation of same styling related code across the project.

3.     Gives a single point of controling the styles across the application.

4.     Improves the performace as the Asp.Net parser now only needs to parse the CSS file once and not do the same parsing of the style for other GridView within a page again.

Problem Generalization: Not only does this apply for GridView, but for any other control we use. Try to make all the styling in CSS as far as possible.

 

 

 

Thanks & Regards,

Arun Manglick

SMTS || Microsoft Technology Practice || Bridgestone - Tyre Link || Persistent Systems || 3023-6258

 

DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.

Microsoft Guidelines to create a good ASP.NET application - Ver 2

Hi,

Following is the checklist to be followed for good ASP.NET application recommended by Microsoft:

Source:

http://msdn2.microsoft.com/en-us/library/ms998530.aspx

Design Considerations

Check	Description
	Consider security and performance.
	Partition your application logically.
	Evaluate affinity.
	Reduce round trips.
	Avoid blocking on long-running tasks.
	Use caching.
	Avoid unnecessary exceptions.

Threading

Check	Description
	Tune the thread pool by using the formula to reduce contention.
	Consider minIoThreads and minWorkerThreads for burst load.
	Do not create threads on a per-request basis.
	Avoid blocking threads.
	Avoid asynchronous calls unless you have additional parallel work.

Resource Management

Check	Description
	Pool resources.
	Explicitly call Close or Dispose on resources you open.
	Do not cache or block on pooled resources.
	Know your application allocation pattern.
	Obtain resources late and release them early.
	Avoid per-request impersonation.

Pages

Check	Description
	Trim your page size.
	Enable buffering.
	Use Page.IsPostBack to minimize redundant processing.
	Partition page content to improve caching efficiency and reduce rendering.
	Ensure pages are batch compiled.
	Ensure debug is set to false.
	Optimize expensive loops.
	Consider using Server.Transfer instead of Response.Redirect.
	Use client-side validation.

Server Controls

Check	Description
	Identify the use of view state in your server controls.
	Use server controls where appropriate.
	Avoid creating deep hierarchies of controls.

Data Binding

Check	Description
	Avoid using Page.DataBind.
	Minimize calls to DataBinder.Eval.

Caching

Check	Description
	Separate dynamic data from static data in your pages.
	Configure the memory limit.
	Cache the right data.
	Refresh your cache appropriately.
	Cache the appropriate form of data.
	Use output caching to cache relatively static pages.
	Choose the right cache location.
	Use VaryBy attributes for selective caching.
	Use kernel caching on Microsoft® Windows Server™ 2003.

State Management

Check	Description
	Store simple state on the client where possible.
	Consider serialization costs.

Application State

Check	Description
	Use static properties instead of the Application object to store application state.
	Use application state to share static, read-only data.
	Do not store single-threaded apartment (STA) COM objects in application state.

Session State

Check	Description
	Prefer basic types to reduce serialization costs.
	Disable session state if you do not use it.
	Avoid storing STA COM objects in session state.
	Use the ReadOnly attribute when you can.

View State

Check	Description
	Disable view state if you do not need it.
	Minimize the number of objects you store in view state.
	Determine the size of your view state.

HTTP Modules

Check	Description
	Avoid long-running and blocking calls in pipeline code.
	Consider asynchronous events.

String Management

Check	Description
	Use Response.Write for formatting output.
	Use StringBuilder for temporary buffers.
	Use HtmlTextWriter when building custom controls.

Exception Management

Check	Description
	Implement a Global.asax error handler.
	Monitor application exceptions.
	Use try/finally on disposable resources.
	Write code that avoids exceptions.
	Set timeouts aggressively.

COM Interop

Check	Description
	Use ASPCOMPAT to call STA COM objects.
	Avoid storing COM objects in session state or application state.
	Avoid storing STA components in session state.
	Do not create STA components in a page constructor.
	Supplement classic ASP Server.CreateObject with early binding.

Data Access

Check	Description
	Use paging for large result sets.
	Use a DataReader for fast and efficient data binding.
	Prevent users from requesting too much data.
	Consider caching data.

Security Considerations

Check	Description
	Constrain unwanted Web server traffic.
	Turn off authentication for anonymous access.
	Validate user input on the client.
	Avoid per-request impersonation.
	Avoid caching sensitive data.
	Segregate secure and non-secure content.
	Only use Secure Sockets Layer (SSL) for pages that require it.
	Use absolute URLs for navigation.
	Consider using SSL hardware to offload SSL processing.
	Tune SSL timeout to avoid SSL session expiration.

Deployment Considerations

Check	Description
	Avoid unnecessary process hops.
	Understand the performance implications of a remote middle tier.
	Short-circuit the HTTP pipeline.
	Configure the memory limit.
	Disable tracing and debugging.
	Ensure content updates do not cause additional assemblies to be loaded.
	Avoid XCOPY under heavy load.
	Consider precompiling pages.
	Consider Web garden configuration.
	Consider using HTTP compression.
	Consider using perimeter caching.

Thanks & Regards,

Arun Manglick

SMTS || Microsoft Technology Practice || Bridgestone - Tyre Link || Persistent Systems || 3023-6258