The Best of Telerik ASP.NET Ajax Controls

Last year in July we decided to buy Telerik Suite here for our team and I think it has been a wonderful decision. At the time, we started working on an highly data intensive application and we had to reduce postbacks using AJAX. I had used ASP.NET Ajax Control Toolkit before (like here) but I found it limited and you still have to do a lot of work around the toolkit controls to actually make them work in more complex scenarios. So we decided to give Telerik controls a go and it has been amazing !

We have used various controls from the Telerik Suite in our applications like RadAjaxPanel, RadEditor, RadToolTip, RadChart, RadGrid, RadInput, RadUpload, RadSplitter, RadWindow. All these controls are useful and not only provide an amazing UI but also reduce the development time considerably, still I have fallen in love with specially two controls RadAjaxPanel and RadToolTip.


Rad Ajax Panel is an enhanced version of UpdatePanel with a wonderful Client Side and Server Side object model to work with. So, just put an RadAjaxPanel around everything you want to Ajaxify.

<telerik:RadAjaxPanel ID="RadAjaxPanel1" runat="server" Height="100%" Width="100%" LoadingPanelID="RadAjaxLoadingPanel1" HorizontalAlign="left"></telerik:RadAjaxPanel>


RadToolTip is an amazing control and can be used in a range of scenarios specially for on-demand loading. You can actually fit a Web User Control in the tool tip and load it on demand on any event on the page. Some of the scenarios where we used the RadToolTip.

Data Validation (Since it can stick to any control on the page)



Dynamic Selection Menu (Loading On Demand User Control)


Dynamic Options (Loading On Demand User Control)


Creating ASP.NET UserControl Libraries for use in Multiple Websites

The Web User Control in ASP.NET is a powerful element to effectively reuse design components within the project. However, there is no standard way to create a Web User Control Library which could be used across mutiple web projects. In my current scenario I want multiple web applications to share the user controls.

Scott Guthrie has explained this here Building Re-Usable ASP.NET User Control and Page Libraries with VS 2005, but he is suggesting to publish the user controls project separately and then copy paste the files in your actual project. This is not very practical if you have multiple applications and a team which is constantly updating the user controls and the applications and continuously checking-in latest controls.

So here goes the solution.

  1. You need to create a Web Application Project instead of a Website project for your User Controls. The reason for this is that the Website project that you create with Visual Studio 2005 cannot be consumed by other projects within the solution. Moreover, since there is no project file, you cannot add Pre-Build/Post-Build events to the project. You will have to download Web Application Project Template for visual studio 2005 since Visual Studio 2005 does not provide this in def ault installation.
  2. OK, after you have the Web Application Project template, create two projects, one Web Application Project (UserControlLibrary) for the User Controls and another ASP.NET Website as shown in the figure.
  3. Now Build the “UserControlLibrary” project which will generate a single DLL (UserControlLibrary.dll) for this project. Now Add a Reference of this project to the other website project.
  4. In order to copy the ASCX files of the controls in UserControlLibrary to the website project, add a Post-Build Event for the UserControlLibrary, to copy all ASCX files to the Website project.
  5. Now add a UserControls folder under both projects and keep all your user controls under the UserControls folder in the UserControlLibrary. Go to the properties of the UserControlLibrary project and then to the Compile Tab, open the Build Options and add the following to the Post Build Event.

    “$(ProjectDir)UserControls\*.ascx” “$(SolutionDir)WebSite\UserControls\” /Y  
  6. After adding the post-build event, whenever you compile your UserControlLibrary project, the DLL will be updated in the Website project because of the reference and the ascx will be copied by the Post Build Event that we just added.

Setting up Google Latitude

Just completed the Google Latitude setup on Blackberry Curve. The process is very simple. I was already using Google Maps 2.0 and just had to download the latest version of the Google Maps and install it, which comes with built-in Google Latitude.

The Latitude is completely opt-in right now and you need to have a Google account and approval from both parties to see each other’s information. A public interface would be good if someone wants to share the location openly on blog etc.


The Five Laws of Project Management

Inspired by the Isaac Asimov’s Three Laws of Robotics, and the Laws of Identity which I posted in the previous entry. I came up with my own Five Laws of Project Management based on my own personal experience in managing projects. (BTW I personally need to improve in these as well.)

Transparency, Boldness & Effective Communication: To me these are the most important personality traits required by a Project Manager. Transparency helps in managing the expectations of all stakeholders including the business, the management and the project team and boldness enables the project manager to remain transparent even in the time of crisis.

Many Project Managers who are not transparent, bold or cannot effectively communicate fail to raise the issues at the right time or bring a true picture in-front of management. The Project Manager should have a strong character and should raise the issues at the right moment. For example, issues like time limitation, lack of resources or unclear scope of work should be raised immediately and with strength. It is much better not to undertake a project or simply say “No” then to fail it, especially when you know in advance you are going to fail and you simply kept quite on that. Similarly, issues with the team like quality of work or delays in deliverables should be immediately highlighted and communicated to the team members. 

Keeping this balance between the business, management and the team through effective communication while still managing the actual work is one of the most difficult challenges.

Documented Scope of Work: Most developers don’t like to write documents, instead they like to code and they start coding during or even before the requirements analysis is complete. Never write even a single line of code without a documented and clear scope of work which has been signed-off by the business or management. The lack of a signed scope of work is bound to put you in a loop. The loop of continuous changes and requests which will go back-and-forth between the client and your team for months if not years.

Also, always keep the scope document updated even with the slightest change in detail during the course of the project and get these updated documents signed. Having an updated and signed scope of work by the end of the project will save you a lot of trouble which generally people go through for project closure.

Team Work: I believe that “Only great teams produce great software”, so be very careful while selecting the team. The limitation of team members in numbers or in competence is one of the biggest reasons for failed projects. Make sure your team members are competent to do their job and are team players.

In case you are stuck with a team which is limited by number or have some members which do not have the required skills and you do not have the control to change or increase the team, then always factor in extra time in the project plan to cover for them.

Never create a project plan without knowing the team members and their skills. Many times I have seen project plans being made only with dummy R1, R2, R3 etc without even knowing or even without hiring the actual team members. Always remember that all team members do not have the same level of expertise and hence tasks cannot be assigned equally to R1, R2, R3.

Time Management: Efficient time management is also a big factor in overall success of the project. Nearly all Project Managers plan a little more time than actually required to complete a tasks, this time is called buffer. The buffer plays an important role for risk management and managing unforeseen issues and problems during the project.

However, in most cases the buffer time is used as a luxury and is wasted in the initial days of the project, either through a slow pace of work or simply relaxing because the project managers feels he has a lot of time on hand. This strains the project and the team at the end and if in case any unforeseen problem really comes along for which the buffer was originally intended, the project is delayed and gets into trouble.

So, never put-off the scheduled work for tomorrow even if you have a lot of extra buffer. Try to complete as much work as you can at the start of the project. Having some time at the end helps in better testing of the product and also helps in improving the product by adding additional (icing) features. It also saves the team from unnecessary strain.

Successful Closure: Celebrate only after fully completing the Job”. Some project managers celebrate the achievement of certain crucial milestones in the project with great enthusiasm and consider the “Job Accomplished” without actually realizing that certain less important modules/tasks in the project are still not complete. This not only gives a wrong perception to the team but also these smaller less important things which are not considered “success factor” , in the end cause the failure or at least undermine the success.

For example, testing and documentation are a few phases which almost always take a hit because the project manager and team celebrate the “end of development” which such enthusiasm that they consider the Job completed and give less importance to the remaining phases. This results in multiple patches, service packs and fixes to the original product undermining the hard work and the success.

The successful closure of the project generally requires as much as hard work as in the start of the project. Becoming less focused at the end of the project always ends in issues which become apparent at a later stage. The Project Manager should remain focused till the Project is fully completed with all phases and in every detail so a true success can be celebrated.

Update 1: Take a look at some of humorous Project Management Laws which I found here.

Laws of Identity

Just came across Microsoft Kim Cameron’s Laws of Identity.

  1. User Control and Consent
  2. Limited Disclosure for Limited Use
  3. The Law of Fewest Parties
  4. Directed Identity
  5. Pluralism of Operators and Technologies
  6. Human Integration
  7. Consistent Experience Across Contexts

The recent study and work for Single-Sign On and Federated Identities made me go through interesting writings regarding federation and identity management from SAML standards to Geneva Framework. More on Geneva Framework later.