 |
The goal of every programmer is to shorten the code as much as possible.
Although for us, Microsoft has done a lot in the form of ASP.NET (Vb.net or C#) controls and lot of namespaces and libraries available that we do not really need to write our code at certain places. |
But those are not business logics. Business logic is what you need to write your way, according to the needs of your client. I write code in the “itemdatabound” event of Listview control as well as the “RowDataBound” event of Gridview Controls. But I thought for a moment that, if there are multiple pages using the same GridView or ListView and more or less same logic in the “RowDataBound” or “ItemDataBound” events then why not I make a centralized event handler? One way to do this is to simply write comma separated Control IDs with the Handles clause
Protected Sub GridView1_RowDataBound(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.GridViewRowEventArgs) Handles GridView1.RowDataBound,GridView2.RowDataBound
End Sub
|
But this approach will only be available for multiple GridView or ListView controls within a single page.
A little tricky but interesting solution for that is to inherit the ASPX pages with another class (say ParentPage).
''page1.aspx.vb
Partial Class page1
Inherits ParentPage
End Class
''page2.aspx.vb
Partial Class page2
Inherits ParentPage
End Class
''ParentPage.vb
Public Class ParentPage
Inherits System.Web.UI.Page
End Class
The above code shows three classes, two are partial classes, of page1.aspx and page2.aspx pages respectively, but you can notice that those two classes are extended by another class called as ParentPage. I replaced the System.Web.UI.Page with ParentClass
The ParentPage class is extended with the System.Web.UI.Page. instead.
The reason to do this obvious, that is to make use of centralized procedures, which I'm going to do below.
Note that the approach of having this ParentPage is not necessarily the only way to do this, but having the events in a Parent class is useful in many ways, such as you are taking advantage of the OO features of using the public procedures of Parent class which are viewable to all child classes, as well as there's no need to instantiate a new object everytime.
Another way could be to use a static (shared in vb.net) method instead. But this approach will have restrictions. Such as you may require to make use of a method exposed by an instantiated object of any other class and definetely the static method will not allow you to do instantiation within its body (code block).
The child pages will call the centralized event procedure as shown in the code below:
Protected Sub GridView1_RowDataBound(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.GridViewRowEventArgs) Handles GridView1.RowDataBound
MyBase.EventHandlerForRowDataBound(sender, e)
End Sub
There may be some pages (such as user controls and master pages) which are not inherited (extended) from the ParentPage class, and they might contain the
GridView or ListView, obviously, then there is a slight change, and instead of Mybase it should be an object on the fly.
Protected Sub GridView1_RowDataBound(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.GridViewRowEventArgs) Handles GridView1.RowDataBound
Call (New ParentPage()).EventHandlerForRowDataBound(sender, e)
End Sub
While this is also obvious, that if there are multiple GridView across multiple pages (master pages, controls, childpages) which are using a centrlized procedure, then there must some GridView specific operations which are particular to some specific GridView control on a specific page. Below code would illustrate a typical look of the event code blocks which I made to control this.
the "sender" object will act here as the source of the event, that is the GridView and we can use the " ID " property (not shown in the intellisence help, and you'll have to type it) if the GridView to differentiate between different GridViews. While you can also make use of the " Page " property of the sender as shown in the following code snippet.
Public Sub EventHandlerForRowDataBound(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.GridViewRowEventArgs)
'Your code should come here
If e.Row.RowType = DataControlRowType.DataRow Then
'Your code here
If sender.id.ToString() = "GridView1" Then
'Some specific operation
ElseIf sender.id.ToString() = "GridView2" Then
'Some specific operation
End If
If sender.page.ToString().Contains("page1") Then
'Some specific
End If
'Common Code Operations
End If
End Sub
To be noted here, is that the Event Delegate signatures must be same to make it work. That means that the procedure must follow the same signature as the actual event of the RowDataBound or ItemDataBound have.
You can learn more about Event Delegates from the following URL.
http://msdn2.microsoft.com/en-us/library/17sde2xt.aspx
Hense the procedure in the ParentPage class, should look like below code.
Public Sub EventHandlerForRowDataBound(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.GridViewRowEventArgs)
'Your code should come here
End Sub
Within the above procedure, you can make use of other objects, which are not static as well as use the Response.Write and all the other methods which are supported by the .aspx page as the ParentPage class it extending from System.Web.UI.Page class.
Moreover, not only the RowDataBound or ItemDataBound event, but this would clear the idea that veriety of events can be centralized this way, according to the business logice of the application you are working on.
Happy Coding !!
PS ! Do not sit for long hours continous while programming, take some walk, have tea (or whatever) to keep your body active, to avoid backache. Because this is not at all co-incidance that I and danish having same problem, both went to doctor, both took pain killer, and now both are advised light excercises........
regards - raheel