Archive

Posts Tagged ‘.Net3.5’

Strategy Design Pattern in .Net

September 26, 2010 Leave a comment

Strategy design pattern falls under the category of Behavioral Design Pattern. In this pattern, we capture abstraction in an Interface or Abstract class called Strategy Base, and we bury implementation details of algorithms in concrete classes called Concrete Strategy. Client code can then call such different implementation methods based upon some strategy or condition during run time. Client is not tied statically or bound to call fixed methods, rather it can change its strategy dynamically. This is because client never calls any methods directly by instantiating concrete classes. Client sets its strategy via some other class called Context.

Let’s see one such example of this pattern.

StrategyDesignPattern
Fig: Strategy Design Pattern showing all three main components- Strategy Base, Concrete Strategy and Context Classes.

Coming to code, we have:

namespace BehavioralDesignPattern.StrategyDesignPattern
{
public abstract class StrategyBase
{
public abstract long Calculate(int x,int y);
}

public class ConcreteAddStrategy : StrategyBase
{
public override long Calculate(int x, int y)
{
return x + y;
}
}

public class ConcreteSubtractStrategy : StrategyBase
{
public override long Calculate(int x, int y)
{
return x - y;
}
}

public class Context
{
public StrategyBase Strategy { get; set; }
public long CallCalculateMethod(int x, int y)
{
return (Strategy.Calculate(x, y));
}
}
}

We see each of the concrete strategy class implementing algorithm to calculate upon numbers in its own way- one doing addition, while other doing subtraction. But their over all capability to do arithmetic operations upon numbers is abstracted inside Calculate(int, int) method in StrategyBase class.

See the Context class above. It has a property Strategy to get-set of type StrategyBase type. Alternatively, Context class can get-set instance of StrategyBase by a constructor or some method as well like SetStrategy(StrategyBase objSB).

But why do we require this Context class? Because clients agree to call any ConcreteStrategy method not directly. Clients will only hint out for such concrete strategy. What does this mean? This means a lot- Strategy pattern lets you change the guts of an object.

See the client code below:

private void CallStrategyAddMethod()
{
//
Context objCtxt = new Context();
objCtxt.Strategy = new ConcreteAddStrategy();
// Now the object's strategy is to call Add method.
objCtxt.CallCalculateMethod(10, 15);
}

As seen from the above code, object “objCtxt” is able to call method in a concrete strategy class.

Whenever modeling a system after Strategy Design Pattern, one has to carefully think of a way to allow client to convey its strategy to context class.

That’s it.

Template Method Design Pattern in .Net

September 26, 2010 Leave a comment

Template method design pattern falls under the category of Behavioral Design Pattern. In this pattern, a template method defines a skeleton of an algorithm in terms of abstract operations. The template method can contain one or more steps. But these steps will have to be in abstract form only. That said, we cannot change the order of steps, and most importantly we cannot override the template method itself. Only the steps given in the skeleton of algorithm of template method need to be overridden in concrete classes.

Let’s see how classes can be designed in this template pattern.

emplateMethodPattern

Fig: High Level Class Diagram of Template Method Design Pattern

And see the code implementation below:

namespace BehavioralDesignPattern.TemplateMethod
{
public abstract class AbstractAlgorithmSkeleton
{
public void TemplateMethod()
{
// Template Method declaring algorithm
// in terms of abstract operations.
Step1();
Step2();
Step3();
}
public abstract void Step1();
public abstract void Step2();
public abstract void Step3();
}

# region "Concrete Implementations of abstract operations defined in Template Method"
public class ConcreteClassA : AbstractAlgorithmSkeleton
{
public override void Step1()
{
Console.WriteLine("ConcreteClassA, Step 1");
}

public override void Step2()
{
Console.WriteLine("ConcreteClassA, Step 2");
}

public override void Step3()
{
Console.WriteLine("ConcreteClassA, Step 3");
}

public void OtherMethodA()
{
//
}
}

public class ConcreteClassB : AbstractAlgorithmSkeleton
{
public override void Step1()
{
Console.WriteLine("ConcreteClassB, Step 1");
}

public override void Step2()
{
Console.WriteLine("ConcreteClassB, Step 2");
}

public override void Step3()
{
Console.WriteLine("ConcreteClassB, Step 3");
}

public void OtherMethodB()
{
//
}
}

# endregion "Concrete Classes Implementation"
}

We see the concrete classes are overriding the abstract operations defined by the template method in its algorithm. This way template method pattern provides an abstract view of algorithm.

So in practical scenario, this pattern fits only when different types of object instances are required to invoke methods or operations that differ sharply in implementation but the algorithm remaining same. Also, sometimes when are refactoring multiple classes, we can find template method pattern coming into picture.

Consuming the template method:

private void CallTemplateMethod()
{
AbstractAlgorithmSkeleton objTemplate = null;
objTemplate = new ConcreteClassA();
// Now this call to TemplateMethod() will direct calls
// to methods in ConcreteClassA.
objTemplate.TemplateMethod();
}

Important point to note here is: the way we are calling TemplateMethod() of ConcreteClassA from base class AbstractAlgorithmSkeleton reminds us of “The Hollywood Principle”- “Do not call us, we will call for you”. That is, child class method is being called from base class. This way of method call is also known as Inversion of Control.

That’s it.

Decorator Design Pattern in .Net

September 19, 2010 Leave a comment

Decorator design pattern falls under the category of Structural Design Pattern. Structural design pattern emphasizes upon the overall structure of classes and objects in the system either by doing class inheritance or by composing objects into larger structures using object composition. Decorator pattern comes handy when we want to add additional responsibilities to the object during run time.

  • Additional responsibilities can be added statically by class inheritance also. But this will create another problem when we want to add such responsibilities to objects of many classes. We may have to create many child classes to support additional new functions.
  • So instead of creating many child classes of already existing concrete classes, we create a new Decorator, and a new Concrete Decorator class that will add new methods and properties to the existing class object during run time. This way we are not modifying the existing concrete or legacy classes. Responsibilities to objects can be added during runtime because base class of the object and Decorator class share the same base type. And Concrete Decorator class extends the new Decorator.

This design pattern does not come initially during system design. It generally comes during maintenance phase or later in the development phase.

Now let’s see the example of decorator design pattern. We even use mobile phone to send text and multimedia messages. Once the message is sent, the Outbox becomes empty. But sometimes we want to save the sent content message. To do this, we need to select the option of “Send and Save”, and any message sent this way will be saved inside “Sent” folders. Here, even if the user may not always want to save the sent messages, it is for sure that he may definitely want to send messages. Keeping this use case in mind, let’s look into such a class design.

BaseMessage
Fig: Base class for SMS and MMS Concrete Classes

Decorator
Fig: Overall class structure after the introduction of Decorator

From the above diagram, we see two main concrete classes that are involved in sending messages- MobileMMS sends image as message content while MobileSMS send text. Both of the classes are doing well with SendMessage() method. SendMessage() is an abstract method in BaseMessage root class. Decorator, often called DecoratorBase, can be seen inheriting from the same base type of these two MobileMMS and MobileSMS classes, i.e.; inheriting from BaseMessage class. For a Decorator class this is important.

Then, we see MessageProcessor class (often called ConcreteDecorator) which is a concrete implementation of Decorator.

Note: BaseMessage, MobileMMS and MobileSMS are the original classes. Only due to SendAndSave option, a new responsibility SaveMessage() is now required to be added into the objects of MobileMMS and MobileSMS. This is how we see DecoratorBase and ConcreteDecorator need to be added later on.

Now let’s see the actual implementation of the classes.

namespace DecoratorPattern
{
abstract class BaseMessage
{
private string _sender;
private string _recipient;
public string MessageSender
{
get
{
return this._sender;
}
set
{
this._sender = value;
}
}
public string MessageRecipient {
get
{
return this._recipient;
}
set
{
this._recipient = value;
}
}
public abstract void SendMessage();
}
}
namespace DecoratorPattern
{
class MobileSMS: BaseMessage
{
private string _message;
public MobileSMS(string strSender, string strRecipient, string strMessage)
{
this.MessageSender = strSender;
this.MessageRecipient = strRecipient;
this.Message = strMessage;
}
public string Message
{
get
{
return this._message;
}
set
{
this._message = value;
}
}
public override void SendMessage()
{
//Send Text message
}
}
}
namespace DecoratorPattern
{
class MobileMMS:BaseMessage
{
private byte[] image;
public MobileMMS(string strSender, string strRecipient, byte[] image)
{
this.MessageSender = strSender;
this.MessageRecipient = strRecipient;
this.Image = image;
}
public byte[] Image
{
get
{
return this.image;
}
set
{
this.image = value;
}
}
public override void SendMessage()
{
//Send MMS message
}
}
}
namespace DecoratorPattern
{
class Decorator: BaseMessage
{
protected BaseMessage message;
public Decorator(BaseMessage message)
{
this.message = message;
}
public override void SendMessage()
{
message.SendMessage();
}
}
}
namespace DecoratorPattern
{
class MessageProcessor:Decorator
{
public MessageProcessor(BaseMessage message): base(message)
{
}
public void SaveMessage()
{
//Saves outgoing message
}
public override void SendMessage()
{
//
base.SendMessage();
SaveMessage();
}
}
}

Now see the SendSMS and SendMMS methods: how the constructor methods of MessageProcessor are accepting object instances. This is called object composition, and important for Concrete Decorator. This way MessageProcessor will be able to direct the call to the actual method of the class. See the SendMessage() method code above in MessageProcessor.

Client Code

namespace DecoratorPattern
{
class Program
{
public enum SendMessageOption
{
SendOnly = 0,
SendAndSave = 1
}
private void SendSMS(SendMessageOption option)
{
//Send SMS
MobileSMS sms = new MobileSMS("123", "456", "This is example of decorator pattern.");
if (option == SendMessageOption.SendOnly)
{
sms.SendMessage();
}
else if (option == SendMessageOption.SendAndSave)
{
MessageProcessor msgProcessor = new MessageProcessor(sms);
msgProcessor.SendMessage();
}
}
private void SendMMS(SendMessageOption option)
{
//Send MMS
MobileMMS mms = new MobileMMS("123", "456", new byte[] { 1, 2, 3, 4 });
if (option == SendMessageOption.SendOnly)
{
mms.SendMessage();
}
else if (option == SendMessageOption.SendAndSave)
{
MessageProcessor msgProcessor = new MessageProcessor(mms);
msgProcessor.SendMessage();
}
}

static void Main(string[] args)
{
//
Program obj = new Program();
obj.SendSMS(SendMessageOption.SendOnly);
obj.SendSMS(SendMessageOption.SendAndSave);
obj.SendMMS(SendMessageOption.SendOnly);
obj.SendMMS(SendMessageOption.SendAndSave);
//Wait for user enter key
Console.Read();
}
}
}

Hope the Decorator design pattern is now simple enough to understand.

Embedding and Using Resources from .Net Assembly

.Net Assemblies can contain various types of resources like images, icons, files, etc. Such resources are mostly static, i.e.; do not keep changing during run time or application wise. Also, such resources are not executable items. So while deploying such assemblies, we need to make sure those resources are intact with the packaged assemblies. Else, assemblies may blow up while executing the resource dependent methods. So as part of deployment strategy, we should embed such resources into the assembly itself.

Today we will see one such example of embedding Xml file into assembly.

  • Add one Class Library type project into the solution.
  • Add one Xml file as well. Fill Xml file with few data that the class library may use to query.
  • Right click on the Xml file, and select Properties –> Build Action. Out of several Build Action options, select Embedded Resource.

ResourceProperties

  • There you may see other properties as well like Copy to Output Directory. It has options like this:

ResourceSettings

  • If you select Do Not Copy, output of building the class library inside \bin\ folder will not have separate *.dll than embedded Xml file.
  • If you select Copy Always, output of building the class library inside \bin\ folder will always have *.dll and an embedded Xml file.

However, I prefer the first option. By this we make sure our distributable assembly is only one *.dll. This way the embedded resource Xml file cannot be modified, and our assembly can safely execute methods that depend upon this Xml file. I like to suggest one more tips here- rename this Xml file extension to *.config. Renaming Xml file extension to *.config makes file not browse able by Browser in web applications.

Here I have shown steps of embedding resource file into .Net assembly. This assembly can be either Class Library or Web application. We cannot embed resource file into web site type project as Web site does not produce assembly like Web application.

Now, let’s see how we can access embedded Xml file from assembly during runtime.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Reflection;
using System.Xml;
using System.IO;

namespace MathLibrary
{
public class MathLibrary
{
//
private const string strFileName = "XMLFile.config";

public System.Xml.XmlDocument GetXMLDocument()
{
//
var assembly = Assembly.GetExecutingAssembly();
var stream = assembly.GetManifestResourceStreamthis.GetType(), strFileName);
var doc = new XmlDocument();

try
{
if (stream == null)
{
throw new FileNotFoundException("Couldnot find embedded mappings resource file.", strFileName);
}
doc.Load(stream);
}
catch (Exception ex)
{ throw ex; }
return doc;
}

public System.IO.Stream GetXMLStream()
{
//
var assembly = Assembly.GetExecutingAssembly();
var stream = assembly.GetManifestResourceStream(this.GetType(), strFileName);

try
{
if (stream == null)
{
throw new FileNotFoundException("Couldnot find embedded mappings resource file.", strFileName);
}
}
catch (Exception ex)
{ throw ex; }
return stream;
}
}
}

There are two methods shown above- one returning XmlDocument object and other returning IO.Stream. Either of the return type can be used to construct XmlDocument object now at caller end of these methods.

Now let’s verify the assembly if it has any embedded resource or not. We can do this using either Reflector or Ildasm tool.

Reflector View:

ReflectorView

Ildasm View:

IldasmView

See resource name is qualified with assembly namespace name prefixed to it- MathLibrary.XMLFile.config.

Happy Coding!

Exception Handling in WCF

We have been doing exception handling in managed application using try-catch block with Exception or its derived Custom Exception objects. But this mechanism is very much .Net Technology specific. When we develop SOA applications, our application is not limited to mere one technology or single loyal client. So the communication process of this service or service method level errors to client via wire becomes a little bit tricky. WCF has two types of error handling mechanism: one is by as usual Exception objects, and other is by SOAP fault message. SOAP fault is used to marshall .Net exceptions to client in much readable and convenient way to support interoperability. With use of SOAP fault, the verbose exception message is reduced to Code and Message. For this System.ServiceModel namespace comes FaultException class and FaultContract attribute.

Let’s come to see from example on how to do exception handling in WCF application. Before this, write our service first.

namespace WcfSvc
{
[ServiceContract]
public interface IBasicMathService
{
[OperationContract]
int Subtraction(int x, int y);

[OperationContract]
int Multiplication(int x, int y);

[OperationContract]
[FaultContract(typeof(BasicMathFault))]
int Addition(int x, int y);
}

[DataContract]
public class BasicMathFault
{
//
[DataMember]
public string Source;

[DataMember]
public string ExceptionMessage;

[DataMember]
public string InnerException;

[DataMember]
public string StackTrace;
}
}

And its implementation is as:

public class BasicMath : IBasicMathService
{
public int Addition(int x, int y)
{
//
int result = 0;
try
{
result = (x + y);
}
catch
{
BasicMathFault ex = new BasicMathFault();
ex.Source = "BasicMath.Addition method";
ex.ExceptionMessage = "Could not perform addition operation.";
ex.InnerException = "Inner exception from math service";
ex.StackTrace = "";
//Throwing strongly-typed FaultException
throw new FaultException(ex, new FaultReason("This is an error condition in BasicMath.Addition method")); }

return result;
}

public int Multiplication(int x, int y)
{
//Due to some calculation error condition, let’s assume we are throwing this error.
//Throwing simply FaultException
throw new FaultException(new FaultReason("Error occurred while processing
for the result"), new FaultCode("mutliplication.method.error"));
}

public int Subtraction(int x, int y)
{
//Exception we generally throw in managed application in the form of Exception object
throw new NotImplementedException("Method still not implemented");
}
}

This is our typical service related code. If we see IBasicMathService interface and its implementation in BasicMath class, we have:

Addition(x,y) method decorated with FaultContract attribute in IBasicMathService class,

Subtraction(x,y) method using simple Exception throwing mechanism,

Multiplication(x,y) method using simple FaultException object, and

Addition(x,y) method using strongly-typed fault of type BasicMathFault in FaultException object

So what does all this mean to client, and how exception is transmitted to client? Let’s answer with these three examples in our client code.

A) Throwing Simple Exception

private void SubtractIntegers()
{
try
{
obj = new BasicmathServiceRef.BasicMathServiceClient();
int result = obj.Subtraction(10, 15);
}
catch (Exception ex)
{
Response.Write(ex.Message + "
");
}
}

When this method is called, client receives verbose error message from WCF as:

“The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.”

If we closely see this error information, we come across two things: turn on\off IncludeExceptionDetailInFaults value either through ServiceBehaviorAttribute of the class containing this method, or modify IncludeExceptionDetailInFaults value in configuration file or section of this service.

Either of these two things is pretty easy.

a) Decorate BasicMath class as:

[ServiceBehavior(IncludeExceptionDetailInFaults = false)]
public class BasicMath : IBasicMathService
{

b) Or, modify in config file

By default this key value is false. If we make it true, the verbose error message that we received will be reduced to human readable message that we passed in constructor of NotImplementedException.

“Method still not implemented”

While debugging WCF exception, one may encounter error in the service like “xyz exception unhandled by user code”. This is some what misleading, but no need to worry.

B) Throw exception of FaultException type

private void MultiplyIntegers()
{
try
{
obj = new BasicmathServiceRef.BasicMathServiceClient();
int result = obj.Multiplication(10, 15);
}
catch (FaultException ex)
{
Response.Write(ex.Message + "");
}
}

On calling this method, WCF will serialize the exception as a Fault message and return to the client as:

“Error occurred while processing for the result”

However, client is unlikely to receive verbose error message if we throw exception of type FaultException even key IncludeExceptionDetailInFaults is true or false. If we see the exception thrown code,

throw new FaultException(new FaultReason("Error occurred while processing for the result"), new FaultCode("mutliplication.method.error"));

we have used FaultCode. Client can use this specific fault code contained in FaultException code to take decision, but this approach becomes more of procedural by many if-else condition to branch out code some thing like:

if (ex.Code.Name == "mutliplication.method.error")
{
Response.Write(ex.Message + "");
}

C) Throwing with strongly typed fault

private void AddIntegers()
{
try
{
obj = new BasicmathServiceRef.BasicMathServiceClient();
int result = obj.Addition(10, 15);
}
catch (FaultException ex)
{
Response.Write(ex.Message + " ");
}
}

With this approach, client will be able to explicitly handle fault of only that type whose service method is to be used by client. Here, we are using BasicMathFault type. At the service level, the specific method has to be decorated with FaultContract attribute so that exception can be serialized as:

[OperationContract]
[FaultContract(typeof(BasicMathFault))]
int Addition(int x, int y);

The detail of fault type is up to our convenient level to let WCF serialize only needful information to client.

When we call this Addition(x,y) method, one may receive this error message if an exception occurs.

“This is an error condition in BasicMath.Addition method”

Thus, we see how we can do exception handling in WCF.

Calling Method in Parent Page from User Control

October 10, 2009 Leave a comment

In ASP.Net, we develop custom user control as a reusable server control independent of any containing parent aspx page. User control has its own public properties, methods, delegates, etc that can be used by parent aspx page. When a user control is embedded or loaded into a page, the page can access public properties, methods, delegates, etc that are in user control. After loading the user control, there a situation may arise like calling methods in page itself. But when a user control is developed, it has no knowledge of containing page. So it becomes a trick to call the page method.

In .Net, Delegate class has one method DynamicInvoke. DynamicInvoke method is used to invoke (late-bound) method referenced by delegate. We can use this method to call a method in parent page from user control. Let’s try with this example.

First create a user control called CustomUserCtrl. Its code will look some thing like this:

public partial class CustomUserCtrl : System.Web.UI.UserControl
{
private System.Delegate _delWithParam;
public Delegate PageMethodWithParamRef
{
set { _delWithParam = value; }
}

private System.Delegate _delNoParam;
public Delegate PageMethodWithNoParamRef
{
set { _delNoParam = value; }
}

protected void Page_Load(object sender, EventArgs e)
{
}

protected void BtnMethodWithParam_Click(object sender, System.EventArgs e)
{
//Parameter to a method is being made ready
object[] obj = new object[1];
obj[0] = "Parameter Value" as object;
_delWithParam.DynamicInvoke(obj);
}

protected void BtnMethowWithoutParam_Click(object sender, System.EventArgs e)
{
//Invoke a method with no parameter
_delNoParam.DynamicInvoke();
}
}

Then add this user control into an aspx page. The code behind of this page is as:

public partial class _Default : System.Web.UI.Page
{
delegate void DelMethodWithParam(string strParam);
delegate void DelMethodWithoutParam();
protected void Page_Load(object sender, EventArgs e)
{
DelMethodWithParam delParam = new DelMethodWithParam(MethodWithParam);
//Set method reference to a user control delegate
this.UserCtrl.PageMethodWithParamRef = delParam;
DelMethodWithoutParam delNoParam = new DelMethodWithoutParam(MethodWithNoParam);
//Set method reference to a user control delegate
this.UserCtrl.PageMethodWithNoParamRef = delNoParam;
}

private void MethodWithParam(string strParam)
{
Response.Write("<br/>It has parameter: " + strParam);
}

private void MethodWithNoParam()
{
Response.Write("<br/>It has no parameter.");
}
}

BtnMethodWithParam and BtnMethowWithoutParam are two different buttons on the user control that are invoking the methods in the parent page. On Page_Load of the page, we are setting the references of page class methods to delegate type properties in the user control. Click different buttons of user control, you will see MethodWithParam(string strParam) and MethodWithNoParam() methods called.

This is all we have to do to call page class methods from user control in ASP.Net.

Load ASP.Net User Control Dynamically Using jQuery

October 10, 2009 5 comments

Today we will explore the way of loading ASP.Net user control at run time using jQuery. jQuery has one method load(fn) that will help here. This load(fn) method has following definition.

load (url, data, callback): A GET request will be performed by default – but if any extra parameters are passed, then a POST will occur.
url (string): URL of the required page
data (map – key/value pair): key value pair data that will be sent to the server
callback (callback method): call back method, not necessarily success

Now comes custom HttpHandler that will load the required user control from the URL given by this load(fn) method. We all know that it is either in-built or custom HttpHandler that is the end point for any request made in ASP.Net.

Let’s see by example. In the ASP.Net application, add one aspx page and user control. Then, add one more class derived from IHttpHandler. The aspx html markup will look something like this.

<html xmlns=”http://www.w3.org/1999/xhtml&#8221; >
<head runat=”server”>
<title>Load ASP.Net User Control</title>
<script src=”jquery-1.2.6.js”></script>
<script>
$(document).ready(function() {
$(“#BtnLoadUserCtrl”).click(function() {
$(“#UserCtrl”).load(“SampleUserCtrl.ascx”);
});
});
</script>
</head>
<body>
<form runat=”server”>
<div>
<br />
<input value=”Load User Control” /> <br />
<div id=”UserCtrl”></div>
</div>
</form>
</body>
</html>

The code is quite readable. On the click event of BtnLoadUserCtrl button, SampleUserCtrl.ascx user control is being tried to load in the <div> element having id UserCtrl.

Then, write our custom Httphandler called jQueryHandler as below.

public class jQueryHandler:IHttpHandler
{
public void ProcessRequest(HttpContext context)
{
// We add control in Page tree collection
using(var dummyPage = new Page())
{
dummyPage.Controls.Add(GetControl(context));
context.Server.Execute(dummyPage, context.Response.Output, true);
}
}

private Control GetControl(HttpContext context)
{
// URL path given by load(fn) method on click of button
string strPath = context.Request.Url.LocalPath;
UserControl userctrl = null;
using(var dummyPage = new Page())
{
userctrl = dummyPage.LoadControl(strPath) as UserControl;
}
// Loaded user control is returned
return userctrl;
}

public bool IsReusable
{
get { return true; }
}
}

Do not miss to add this HttpHandler in the web.config.

<httpHandlers>
<add verb=”*” path=”*.ascx” type=”JQUserControl.jQueryHandler, JQUserControl”/>
</httpHandlers>

This web.config configuration tells that jQueryHandler will process request for file type having .ascx extension and methods all (GET, POST, etc). The type attribute value is something like:
type=”Namespace.TypeName, Assembly name where Handler can be found”

Now we are ready to test our sample. Run the page, and see on the click of button, the sampleusertCtrl.ascx is loaded.

I hope we can now extend this concept to fit any such programming requirement in future.
Happy Coding!