Todd Anglin's blog

Telerik Q2 2009 Release Week Webinars

Todd Anglin — Fri, 03 Jul 2009 00:32:18 GMT

[Cross posted from Telerik Watch]

Smell that? That's a freshly baked release from Telerik that's just about ready to "officially" launch. The Q2 2009 release is one of the biggest releases in Telerik's history, again delivering simultaneous updates to all 7 Telerik product lines at one time. An update of this scale is bound to have lots new and interesting stuff, and we can't wait to put it in your hands so you can start playing with it. The official launch of Q2 2009 is Monday, July 6th, and to help you jump-off with the new bits and maximize your productivity with the Telerik tools, we'll be running another release "Webinar Week."
But before I reveal the schedule for the Webinar Week, let me tell you about the prizes!
There will be two ways to win prizes during the Q2 Webinar Week:

Every webinar will award 1 or 2 (depending on the products covered) individual product suite licenses to the people that attend the live event. All you have to do to enter is show-up to the live event and you will be in the pool for a randomly selected winner at the conclusion of the webinar (winners will be notified via email, so don't register with a spam address unless you don't care to claim your prize).
For every live webinar you attend during the webinar week, you will also be entered in the drawing for the Webinar Week Grand Prize: a Telerik Premium Collection license (valued at $1300) and a pass to the 2009 PNP Summit (a $1900 value)! The more webinars you attend live, the better your odds are at winning the prize valued at over $3000.

Plus, to get things kicked-off with a bang, we will be giving away a Premium Collection license to the winner of the first live webinar drawing (instead of a individual suite license), so you definitely don't want to miss the live events.

Now for the schedule. Things get kicked-off on Tuesday, July 7th and run through the end of the week. Webinars will be held everyday at 11:00 AM Eastern Time and all will be recorded for Telerik TV on-demand viewing. The topics covered will be:

Tuesday, July 7th - Q2 2009: What's New?
Join me for a general overview of the Q2 release and high-level intro to what's new
PRIZE: 1 Premium Bundle Collection license
Register for webinar now
Wednesday, July 8th - RadControls for ASP.NET AJAX and WinForms
Join me again for a more in-depth look at what's new in the RadControls for WinForms and ASP.NET AJAX
PRIZE:1 RadControls for ASP.NET AJAX license, 1 RadControls for WinForms license
Register for webinar now
Thursday, July 9th - OpenAccess ORM
Join Telerik DE Gabe Sumner for a closer look at what's new in Telerik OpenAccess ORM
PRIZE: 1 OpenAccess ORM license
Register for webinar now
Friday, July 10th - RadControls for Silverlight / WPF
Join Telerik DE Evan Hutnick for a closer look at what's new in the RadControls for Silverlight and the RadControls for WPF
PRIZE: 1 RadControls for Silverlight license, 1 RadControls for WPF license
Register for webinar now

Registration links for the webinars will be available very soon, so be sure to register early to save your seat. The Q2 2009 Webinar Week is the best way to get started with the Telerik Q2 2009 release, and with all the great prizes to go around, you definitely don't want to miss these free events. We'll see you live next week!

Gracefully degrade RadChart for Silverlight in ASP.NET

Todd Anglin — Thu, 21 May 2009 22:18:38 GMT

In a recent webinar, I showed an example of how you can build a superior user experience in an ASP.NET website by using RadChart for Silverlight. The Telerik Silverlight chart has animations, rich rendering, and is much more visual appealing than the “static” RadChart for ASP.NET. But while the Silverlight chart is a great way to enhance data visualizations in your ASP.NET site, how do you handle users that don’t have Silverlight installed?

One approach is to implement “graceful degradation.” Graceful degradation is an important and familiar principle in web design, and essentially it means this: if you build features into your site that take advantage of the latest and greatest technologies (like Silverlight), make sure you have some mechanism to provide an alternative experience for those users not living on the cutting edge. In our case, that means if Silverlight is not installed, we still want to display a chart, it just wont have the bells and whistles Silverlight offers. Specifically, we want our site to automatically display a RadChart for ASP.NET (which is simply an image generated on the server and sent to the client, so it works on all browsers) if Silverlight is not available.

SIVLERLIGHT’S “NOSCRIPT” TAG

Similar to the HTML <noscript> tag, which is used to display content only when JavaScript is not available, the ASP.NET Silverlight control has a handy template called the “PluginNotInstalledTemplate.” Any content you place inside of this template will be automatically displayed to the user if Silverlight is not installed. If you do not specify any content for this template, Microsoft will display the “Install Silverlight” image by default.

<asp:Silverlight ID="xamlChart" runat="server" Source="~/ClientBin/RadChartControl.xap"

 MinimumVersion="2.0.31005.0">

 <PluginNotInstalledTemplate>

 <!-- Any content can be placed here, including ServerControls -->

 </PluginNotInstalledTemplate>

</asp:Silverlight>

If you are not using an ASPX page to host your Silverlight, you can accomplish a similar feat in raw HTML by adding any content you want between the opening and closing Silverlight HTML <object> tags, like this:

<object data="data:application/x-silverlight," type="application/x-silverlight-2"

 width="100%" height="100%">

 <param name="source" value="ClientBin/RadChartControl.xap"/>

 <!-- Your HTML content here will be displayed if Silverlight is missing -->

</object>

We’ll focus primarily on the ASP.NET experience, though, since it is obviously required for our RadChart “graceful degrade” scenario.

ENABLING THE GRACEFUL DEGRADE

While many people are aware of the PluginNotInstalledTemplate, not as many seem to be aware of the fact that you can include ServerControls in this template. That means we can include a RadChart for ASP.NET AJAX in our plug-in template and easily configure it, just as we would on any other ASP.NET page.

<asp:Silverlight ID="xamlChart" runat="server" Source="~/ClientBin/RadChartControl.xap"

 MinimumVersion="2.0.31005.0">

 <PluginNotInstalledTemplate>

 <!--RadChart for ASP.NET to display if Silverlight not available-->

 <telerik:RadChart ID="RadChart1" runat="server" AutoLayout="true" Skin="Black">

 <Series>

 <telerik:ChartSeries Name="Series 1">

 </telerik:ChartSeries>

 </Series>

 </telerik:RadChart>

 </PluginNotInstalledTemplate>

</asp:Silverlight>

Then, in the code behind of our ASP.NET page (or UserControl, depending on your implementation), we simply bind and render the chart when the page loads.

protected void Page_Load(object sender, EventArgs e)

 //Bind the RadChart to enable "graceful degredation"

 //Get the RadChart from the Silverlight PluginNotInstalledTemplate

    var chart = xamlChart.FindControl(RadChart1.ID) as RadChart;

 if(chart != null)

 //Configure and bind your RadChart (example settings)

        chart.ChartTitle.TextBlock.Text = ChartTitle;

        chart.Width = new Unit(Width);

        chart.Height = new Unit(Height);

        chart.DataSource = JsonData.FromJSON<List<CategorySalesFor1997>>();

        chart.DataBind();

And that’s it. With this simple setup, you can display the Silverlight RadChart when Silverlight is available and the ASP.NET chart image when it’s not. This same principle can be applied to other Silverlight/ASP.NET controls, such as RadUpload, so this is not something that only works with RadChart.

THE RESULTS

When implemented correctly, the end result is seamless for your users. If an user has Silverlight installed, they will see the RadChart for Silverlight, like this:

If they do not have Silverlight installed, they will automatically see the more accessible RadChart for ASP.NET AJAX, like this:

I hope this technique helps you effectively leverage Silverlight in your ASP.NET projects without worrying about leaving your non-Silverlight users behind!

Telerik Web Mail Demo on Azure

Todd Anglin — Tue, 19 May 2009 23:09:56 GMT

I recently showed you how to get started working with the RadControls for ASP.NET AJAX on Azure. It’s really a lot easier than you might think. If you missed the first two posts (and the follow-up videos), here they are for quick reference:

RadControls for ASP.NET AJAX on Azure

Deploying RadControls to Azure

Azure Videos on Telerik TV

Today, I updated the live running Telerik demo on Azure to feature the complete Telerik Web Mail demo! That means you can now see almost all of the RadControls for ASP.NET AJAX running live on the Azure Cloud. Included in the demo are RadGrid, RadEditor, RadSplitter, RadMenu, RadAjax, RadTreeView, RadCombobox, RadScheduler, RadCalendar, RadWindow, RadSkinManager, RadStyleSheetManager, RadScriptManager, and RadPanelBar. This should be full “proof” that you’re ready to go if you want to build new applications for the Azure cloud with the RadControls for ASP.NET AJAX.

But what if you’re thinking about porting an existing app built with the RadControls to the cloud in the future? Fortunately, as the new live demo proves, that’s easy, too. The Web Mail application running on Azure is the exact same source as the app running off the cloud. The only change I’ve made- that is still a work in progress- is changing the way data access works (since I can’t run SQL Express on the Azure cloud…yet). Currently the app is using “dummy data” and XML data, but soon it will be wired-up to a external WCF service layer that will return database data to the cloud app. And whenever SQL Data Services for Azure makes table-based storage available, the demo will feature even more cloud integration.

There are a few features and pages (such as the Contacts page) that don’t currently fully function as a result of these data binding changes, but for the most part, you can interact with the app as normal and see the RadControls functioning correctly. So whether the cloud is for you or not, Telerik is here and ready to support your cloud UI development efforts!

View the Web Mail demo running live on the Azure cloud

Azure videos now on Telerik TV

Todd Anglin — Thu, 07 May 2009 23:55:00 GMT

If you followed my posts last week, you learned that the RadControls for ASP.NET AJAX are “cloud ready.” You can take the RadControls for ASP.NET AJAX that you know and love today and confidently use them in Cloud Service applications that target the Microsoft Azure cloud environment. In case you missed those posts, you can catch-up now:

RadControls for ASP.NET AJAX on Azure

Deploying RadControls to Azure

I’m happy to relay that the videos that are related to these blog posts are now both available on Telerik TV for your immediate viewing pleasure. Each video illustrates the concepts defined in the blog posts, and together they should give you a complete overview of how you start, build, and deploy an ASP.NET application to the cloud with the RadControls. Both videos also check-in at less than 10 minutes, so they should be easy to digest- quick and to the point. Check the videos out at the following links:

Getting Started with RadControls in Azure

Deploying to the Azure Cloud

I hope you enjoy these additional resources. Also, don’t forget that there is a “live” app running in the cloud at http://telerik.cloudapp.net that shows some RadControls running live on Azure. That app will be updated very soon to include even more of the RadControls, so check back soon to see an expanded demo running in the cloud.

Enjoy.

Designing N-Tier Applications with OpenAccess ORM

Todd Anglin — Tue, 28 Apr 2009 11:15:00 GMT

A very important question recently crossed my inbox, and it essentially asked:

“Can you design and build Enterprise-grade n-tier applications with OpenAccess? Or does it force you violate principles of good multi-tier application design to make the ORM features work?”

It was a great question and I was surprised to find that there is not more info in the online docs to address this. So, to help everyone benefit from this question’s answer, here are some details about building n-tier applications with OpenAccess.

WHAT DOES GOOD N-TIER ARCHITECTURE LOOK LIKE WITH OPENACCESS?

Let me preface this discussion by saying there is no “absolute” right or wrong way to architect an application. The approach highlighted here is just one way that will help you build applications that use OpenAccess with clean separation of concerns and respect for principles of multi-tiered application design. With that out of the way, a “typical” multi-tier app built with OpenAccess should look something like this:

Entities (or Model): Contains your persistent classes; Project is “OpenAccess Enabled” to define Persistent Classes (PCs) and includes DB mapping info in the config file. The persistent classes in this project can be created via the Forward or Reverse Mapping OpenAccess wizards.
Data Layer (Optional): Optional, in my opinion, since the actual “data plumbing” will be handled “automatically” inside OA. I prefer to skip this layer, but it can be used for storing your LINQ queries and returning data to your business layer, if desired (and if you don’t want LINQ in your business layer).
Business Layer: Provides “Repository” (or “Manager”) classes that define operations on model (such as FindAll, FindById, Insert, etc.). Acquires ObjectScope used to manipulate objects in the database. “OA Enabled” to consume PCs, which adds ObjectScopeProvider to project (but does not add mapping info to project)
Service Layer (Optional): To build an app that is ready for client-oriented technology (like Silverlight and ASP.NET AJAX 4.0), it is usually smart to build a service layer on top of your business logic. The service layer consumes your business layer “data manager” classes and exposes the operations as service endpoints.
Presentation Layer: Consumes business layer repositories (if no service layer) or consumes services. The presentation layer can be completely ignorant of OpenAccess and it has no need to be “OA Enabled.”

The project linking would look some like this:

Presentation consumes Services consumes Business consumes Data (if present) consumes Model

The only time you might “break” this direct inheritance tree is if you want to re-use your model classes in your other tiers for easier data binding (i.e. I want to bind to return a List<ModelType> vs. some intermediate class type). Still, in that case, you’re only using the class model for binding- you’re not doing any data access outside of your data access tier. Here is the same architecture in picture:

WHAT PROJECTS NEED TO BE OPENACCESS ENABLED?

One of the bigger points of confusion when it comes to using OpenAccess in n-tier applications seems to be which layers require you to run the “OpenAccess Enable” wizards. To be clear, there are two types of OpenAccess enabling provided by the wizard in Visual Studio:

1. Project Defines Persistent Classes: Adds configuration info to App.Config containing DB mappings, Adds refs to OA assemblies

2. Project Consumes Persistent Classes/Connects to DB: Adds references to OA assemblies, Adds ObjectScopeProvider class (for help managing ObjectScope), Adds connection info to project configuration file

In general, the only layers that need OA enabling are your model (where your persistent classes are defined) and your Data or Business layer (or whichever layer you’re using to actually execute queries against the DB).Other layers, like your Presentation layer, do not need to be enabled. And in all cases, when you run the wizard, you’re not adding references to other projects in your solution- just to the OpenAccess assemblies.

I hope that helps clear-up the general approach to using OpenAccess to build n-tier applications. OpenAccess is definitely powerful enough and flexible enough to handle Enterprise architectures, so it’s usually just a matter of understanding how and not if OpenAccess can do what you want.

Web 2.0 font sizes with RadInput

Todd Anglin — Wed, 22 Apr 2009 17:52:10 GMT

If you’ve spent much time visiting “web 2.0” sites, you know that large font sizes are totally “in vogue” for data entry forms. Not only are they easy for all audiences to read, but they also imply a certain level of simplicity on a website. In fact, there are even some UX experts suggesting larger font sizes are better now that high-resolution monitors are the norm and not the exception.

If you’ve got a “beautifully designed” web 2.0-style site, though, and you’re working with RadInput, you know that the default skins “force” their own font size. What do you do if you want the powerful real-time input validation of RadInput and your big web 2.0 fonts?

Fortunately, the problem is easy to solve with a very slightly customized RadInput skin (which is available at the bottom of this post). Essentially, the custom skin just removes the CSS “font-size” declarations from the RadInput Default skin, enabling your RadInput controls (which includes textboxes configured with RadInputManager) to inherit the font-size from your site’s main CSS definition. The effect transforms a form with RadInput from this:

To a form with RadInput’s inheriting the larger page font size:

Now you can take advantage of all the power RadInput and RadInputManager provide without disrupting your “web 2.0” look and feel. To use the custom skin (again, provided below), you simply need to follow these steps:

Copy the “Input.Basic.css” and “Input” folder in the attached ZIP to your App_Themes folder
Make sure your page is configured to use the Theme containing your custom skin (via the Page-level Theme property)
On your RadInput or RadInputManager controls, set EnabledEmbeddedSkins to False and set the Skin property to “Basic”

And that’s it! I hope you enjoy the custom skin and I hope this helps those of you working with “web 2.0” designs better leverage RadInput.

Download custom skin “Basic” for RadInput

Deploying RadControls to Azure

Todd Anglin — Fri, 17 Apr 2009 16:47:35 GMT

In the first part of this short series covering the RadControls for ASP.NET AJAX in the cloud, I showed you how you could quickly (and easily) start a new Azure Cloud Service project, add the RadControls, and then debug the project locally. The next step, of course, is taking that locally built and debugged project and deploying it to the “real” cloud fabric, hosted by Microsoft in their data center (not yet data centers…). That is where the rubber meets the proverbial road and we find out if the Telerik RadControls are really “cloud ready.”

HOW DO YOU DEPLOY TO AZURE?

Assuming you’ve built a new cloud service application (using the VS template) and you’ve debugged it locally and everything is working, you only need to complete these steps to deploy your app to the cloud:

In Visual Studio, right-click on the “Roles” project (not the “Web” project that has your .aspx files) and select “Publish…”
Visual Studio will now build and package your project for Azure
- IMPORTANT NOTES:
- 1) You must use the context menu to Publish the project. The Publish option from the Build menu does not perform the correct actions.
- 2) The Publish step bundles all files required to deploy your project to Azure, including the RadControls assembly
Once the project is done publishing, VS will automatically launch your default browser and direct it to the Azure Developer Portal. VS will also automatically open the folder that contains the two files produced by the Publish action: YourProjectName.cspkg and YourProjectName.cscfg
Log-in to Azure and (assuming you have a CTP token) create a New “Hosted Services” Project
After you’ve given the project a name and description, click the “Deploy…” button under the “Staging” cube icon
Upload your .cspkg and .cscfg files via the provided form
Wait for an unknown length of time (could be as short as seconds or as long as 30 minutes) for project to “Deploy”
Once the “Deploy” step is done, you need to click on the “Run” button to start your Azure “server” instance
Wait for an unknown length of time (could be seconds, could be much longer) for project to start
When project starts, you’ll see “WebRole” and a message indicating that the state is “Initializing”
Continue to wait
When the state finally changes from “Initializing” to “Started” (with a green icon), your Cloud Service site is ready for viewing
Click on the temporary staging link and see your project running live on the cloud!

Assuming you’ve done everything correctly and you’ve patiently waited on all of Azure’s seemingly endless processes to complete the processing, you’ll have a site running live on the cloud with the RadControls for ASP.NET AJAX providing their familiar rich-UI.

HOW ‘BOUT THE GOTCHAS?

There really aren’t any new gotchas here. The only thing that may surprise you is the waiting. You really do have to have some patience to deploy a project to Azure (at least during the CTP), so be prepared to wait for ten minutes or more for some Azure processes to finish. Otherwise, things are very straight forward. Visual Studio packages your files and configuration. Azure consumes those packages directly. You click buttons and your site runs (in theory).

I NEED VISUAL PROOF

For those of you hoping to “see it to believe it,” I’ve got you covered. I have created two videos (so far) that cover both creating and deploying a simple “app” with the RadControls for ASP.NET AJAX to Azure. Both videos will be on Telerik TV soon and I’ll be sure to add links to this post when they’re ready. Until then, have fun playing with Azure and don’t be afraid to use your RadControls for ASP.NET AJAX as you tackle the cloud!

RadControls for ASP.NET AJAX on Azure (Part 1)

Todd Anglin — Mon, 13 Apr 2009 17:37:44 GMT

Those of you paying attention to “conference news” are probably aware of Microsoft’s entrance in to the cloud computing space via their platform code-named “Windows Azure.” This version of “Windows in the cloud” essentially makes it possible to easily build and deploy .NET web applications to Microsoft’s hosted cloud infrastructure. The benefits of deploying your application to the cloud are (potentially) many, but I am going to assume you are already aware of the key “selling points” (such as scalability, scalability, and…oh yeah, scalability).

TELERIK IS CLOUD READY

I’m pleased to report that Telerik is “Cloud Ready.” This is a bit of a funny statement to make, but it is true. The humor is rooted in the fact that there is really nothing special about being “cloud ready.” You can use the exact same RadControls for ASP.NET AJAX that you know and love today to build applications for the cloud. In fact, the process for building your web applications is so familiar, it hardly needs any introduction. Deployment is a little different, but once you get the hang of it you’ll be able to rapidly build cloud applications with Telerik’s RadControls and have them running happily on the cloud with very little trouble.

HOW DO YOU GET STARTED?

Like I said, the process is very, very familiar if you’ve ever developed a web application in Visual Studio, but just to make sure there is no confusion, here’s what you need to do:

Install the Azure SDK and VS Tools (in other words, get your environment setup)
In Visual Studio, navigate to File > New Project… > Cloud Service > Web Cloud Service and create a new project
Once the project is created, you’ll see a web project with a Default.aspx. Edit this like you “normally” would with an ASP.NET project, including dragging and dropping RadControls on the page.
Once you’re ready to test your site on the “Cloud Fabric,” simply press F5 and the Azure Tools for VS will automatically spin-up the local developer fabric (that simulates the cloud on your dev PC) and run your web app.
Rinse and repeat until you’re happy with your site.
Once happy, you’re ready to deploy to the “real” cloud fabric (more on this in the future)

And that’s really all there is to it. In the near future, I’ll be composing some videos for Telerik TV showing you the RadControls running on Azure, but I wanted you to know you can start your tests today without any trouble. Unless…

WINDOWS 7 GOTCHA

If you’re like me, you’re exited about Windows 7 and you’re running it as your full-time OS. Unfortunately, Windows 7 currently has a bug that prevents Azure from working properly on your dev PC. Your solution? You only have two choices at this point in time:

Wait for the next build of Windows 7 (which will likely ship at TechEd next month), OR
Do your Azure development on a Windows Vista or Server 2008 VPC

It’s unfortunate that these two Microsoft beta/CTP tools don’t yet get along, but I suppose pre-release software can’t be perfect. Fortunately, your RadControls are ready to go, so give ‘em a try and enjoy developing applications for the cloud! Watch for more updates, demos, and videos soon.

Optimization Tip: RadCompression for ViewState

Todd Anglin — Fri, 27 Feb 2009 14:58:37 GMT

A few weeks ago, I showed you how you can use the new RadCompression HttpModule found in the RadControls for ASP.NET AJAX Q3 2008 SP2 (and later) to easily (as in, automatically) compress your Ajax and JSON web service communication. While that technique is great for improving the performance of modern web apps that do lots of processing client-side, that’s not the only thing RadCompression can do. It can also automatically compress ViewState! This week, I’ll show you how you can quickly enable ViewState compression and show you the effects it has on overall ViewState size and server performance.

HOW DO I ENABLE VIEWSTATE COMPRESSION?

Enabling ViewState compression with the RadCompression module really couldn’t be easier. It requires no changes to your code, no changes to your markup, and not even a change to your web.config (assuming you’ve already added the required HttpModule references from the previous article). The only thing you need to do is add a new Browser file to your web project (or modify your Browser file if you’re already using one). To add a new Browser file, follow these simple steps:

Right-click on your web project, select “Add…” > “Add ASP.NET Folder…” > “App_Browsers”
Right-click in your new App_Browsers folder, select “Add…” > “Add New Item…” > “Browser File”
The new browser file will have some default values, feel free to delete everything and then add this code:

XML (in your .browser file)

<browsers>

 <browser refID="Default">

 <controlAdapters>

 <adapter controlType="System.Web.UI.Page" adapterType="Telerik.Web.UI.RadHiddenFieldPageStateCompression" />

 <!--Uncomment the following line to use SessionStateCompression and remove ViewState from the page-->

 <!--<adapter controlType="System.Web.UI.Page" adapterType="Telerik.Web.UI.RadSessionPageStateCompression" />-->

 </controlAdapters>

 </browser>

</browsers>

And that’s it! Really. Run your project at this point and you’ll discover that the RadCompression module is now automatically compressing your ViewState.

HOW MUCH DOES THE COMPRESSION HELP?

ViewState, as you probably know, is just a serialized string of data. By default, it’s not compressed, it’s not encrypted, and it’s often a bloated piece of string data that gets passed back and forth with every request to the server (even Ajax requests if you’re using UpdatePanels). Compressing this data is an easy way to reduce your page size and reduce the number of bytes you must send and receive from the server.

To demonstrate RadCompression’s effectiveness, I created a simple page with a RadGrid that loads data from the AdventureWorks Employees table. I bound my grid declaratively (which means all bound data will end-up in ViewState) to an EntityDataSource and I slowly started “cranking-up” my Grid’s page size- from 10 records to 240 per page. As I cranked-up page size, obviously my ViewState grew. I ran 7 tests with and without RadCompression and the results are below:

RadCompression Efficiency

The blue bars represent the ViewState size (in KB) with RadCompression. The green bars represent the difference in the original ViewState size (i.e. total size with no compression). And the red numbers indicate the compression “efficiency” at each step (for instance, “53%” means the compressed ViewState was 53% smaller than the original). You should note a few things about this chart:

As the original ViewState grew, the compression became even more “efficient” (ranging from 47% to 75% compression ratios)
In the first two tests, there was no difference between the original and the “compressed” output – more on this in a moment
On average, RadCompression reduced ViewState size by 61%! (omitting the “0” tests)

So why are the first two tests “0%”? RadCompression actually has a “threshold” that must be passed before compression will kick-in. For smaller ViewState sizes, it doesn’t make sense to apply compression- the overhead of the processing and compression header/footer offset the small gains in overall state size. Currently, this threshold is 8KB. If your original ViewState is smaller than 8KB, RadCompression will automatically skip over it. Bigger than that, and RadCompression will automatically kick-in.

WHAT IS THE EFFECT ON SERVER PERFORMANCE?

Many people will often say, “Sure you can compress ViewState, but doesn’t that add significant processing overhead on the web server?” It is true that adding compression represents extra CPU cycles and it does have an effect on server performance. With RadCompression, though, that impact is relatively small. Internally, RadCompression uses Deflate compression to compress and decompress state, which is much faster than Gzip compression. And thanks to the optimizations of the compression APIs in .NET, the overall effect on server processing time is low.

To test this, I took our same test page and used a .NET Stopwatch (System.Diagnostics.Stopwatch) to test the time it took the server to process our page. I started the timer in OnPreInit and stopped it at the end of OnRender- a cycle the fully captures the loading and saving of ViewState. I then ran 6 tests and measured the server time (in milliseconds) with and without RadCompression enabled. For testing purposes, I chose to test the page configuration that had “70%” efficiency since this should represent a fairly large amount of compression work. Here are the results:

The blue bars represent the original server time; the green represent the server time with compression enabled. (NOTE: This is not page load time, which I often test in these Optimization Tips. This is strictly a measurement of the effect on server processing time.) What you can gather from this graph is that there is no clear disadvantage to using compression. Sometimes a page with compression processes faster than a page without. Sometimes the reverse is true. When you crunch the numbers, compression turns-out to only impact server processing time by 10% on average. In absolute terms, we’re talking about a difference of 10 milliseconds.

And remember, this is server time. The page with compression- which has shaved ViewState size by 70%- should ultimately beat the original page’s overall load time because it has less data to send over the wire and less data for the browser to process. You will have to run your own tests to determine if the server cost is worth the savings in page state size for your site, but based on these tests, you are likely to come-out ahead with compression.

TIP SUMMARY

This may be one of the easiest ways to help reduce your page size, and in turn, help improve your page performance. By simply registering the RadCompression HttpModule and adding a .browser file to your project, you can see reductions of over 70% in your ViewState size with little impact on your server performance. Clearly, as developers we should all be taking active steps to reduce our ViewState size, but if you’ve already done everything you can (or at least everything you have time for) and you want to squeeze a few more KB out of your page, RadCompression is ready and waiting for you in your Telerik toolbox.

Enjoy!

Handling OnAjaxRequest in Content Pages with Ajax Proxy

Todd Anglin — Wed, 25 Feb 2009 12:20:53 GMT

Here’s a quick tip for those of you using RadAjaxManager and RadAjaxManagerProxy. The scenario:

You have a MasterPage with a RadAjaxManager and a ContentPage with a RadAjaxManagerProxy (so far, so good, and you’re following Telerik’s best practice guidance). All declarative Ajax settings work fine with the Proxy- no trouble. But now you want fire an Ajax event on your ContentPage manually using JavaScript and handle the AjaxRequest event on the server. You’re shocked to discover there is no “AjaxRequest” event for the RadAjaxManagerProxy! What’s the solution?

Fortunately, the solution is easy. The RadAjaxManagerProxy is designed to make it easy to configure Ajax settings in complex MasterPage, ContentPage, and UserControl scenarios, but it doesn’t expose the events that the “parent” RadAjaxManager exposes. To use those events on a content page, you must simply get a reference to the parent RadAjaxManager (via a handy static helper method) and then setup your “manual” Ajax setting in code, like this:

C# (in your ContentPage with the Proxy)

//In your ContentPage OnPageLoad

protected void Page_Load(object sender, EventArgs e)

 //Get reference to AjaxManager (from Master)

    var manager = RadAjaxManager.GetCurrent(this);

 //Create a new delegate to handle the AjaxRequest event

    manager.AjaxRequest += new RadAjaxControl.AjaxRequestDelegate(YourContentPage_AjaxRequest);

 //Add your ajax settings programmatically (with ref to Master manager)

    manager.AjaxSettings.AddAjaxSetting(manager, this.controlToUpdate);

//Handle the Ajax event in your ContentPage code behind

private void YourContentPage_AjaxRequest(object sender, AjaxRequestEventArgs e)

 //Optionally process supplied event arg

 switch (e.Argument)

 case "SomeEventArgument":

 //Do something

 break;

With this code in place, you can handle your OnAjaxRequest server-side event in your ContentPage code-behind when the Ajax event is execute from your JavaScript code, like this:

JavaScript (in your ContentPage with Proxy)

function someJavaScriptFunction() {

 //Get reference to RadAjaxManager on page

 if (radManager == null)

       radManager = $find('<%= RadAjaxManager.GetCurrent(this).ClientID %>');

 //Fire ajax request (optionally pass an event arg value)

   radManager.ajaxRequest("SomeEventArgValue");

Just that simple! The key to both the JavaScript and C# code is the static “RadAjaxManager.GetCurrent()” method, which quickly gives you a reference to the “top level” RadAjaxManager in a ContentPage or UserControl. With that method in hand, you can easily tackle advanced scenarios with the RadAjaxManager and the Proxy control.

Check out more, including how to handle OnRequestStart and OnRequestEnd client-side events on ContentPages, in the RadAjax docs

Telerik on Windows 7 Beta – The Complete Overview

Todd Anglin — Mon, 16 Feb 2009 16:39:21 GMT

For those of you that follow my TelerikWatch blog, you know that I recently made the jump to Windows 7 on my primary workstation (build 7000, to be exact). I’ve spent the weekend installing, tweaking, and testing the latest iteration of Windows, and like Vassil before me, my impressions are generally positive. Microsoft has definitely worked hard to ensure the compatibility nightmares of the XP to Vista jump are not repeated with Windows ~~6.1~~ 7. I’m confident I’ll be able to use Windows 7- even in beta form- reliably as my full-time OS from this point forward.

As far as Telerik is concerned, all lights are green. I have successfully installed all of Telerik’s products on Windows 7:

RadControls for ASP.NET AJAX (2008.3.1314)
RadControls for WinForms (2008.3.1321)
RadControls for WPF (2008.3.1217)
RadControls for Silverlight (2008.3.1217)
Telerik Reporting (2008.3.1402)
Telerik OpenAccess ORM (2008.3.1327.2)
Telerik WebUI Test Studio Beta

My environment is running VS 2008 SP1 and SQL Express 2008. All of the installers ran without error and behaved as expected. I did have some challenges running the installers at first, but a quick reboot of Windows 7 cleared the problem. If you have challenges with Windows 7 beta (really for installing anything), I suggest you first try re-running the installer as “admin” and then, if that fails, try rebooting and installing again. That’s worked for me for just about everything.

The ASP.NET AJAX, WinForms, WPF, Reporting, and OpenAccess installers all add their Visual Studio toolbox items and Visual Studio menus without problem. The OpenAccess and Telerik Reporting installers also installed their test databases (NorthwindOA and AdventureWorks, respectively) on SQL Express 2008 without problem.

The story carries over for design-time experience, too. The Telerik Reporting designer and wizards work without issue. The OpenAccess wizards and dialogs work without issue. And, of course, Telerik’s brand-new WebUI Test Studio test recorder and playback work. One important thing to remember is that you need to run Visual Studio as “admin” for all features to work. For instance, you may see a permissions error when trying to preview a Telerik Report in Visual Studio unless you are running as admin. Otherwise, no surprises.

CONCLUSION

Windows 7 beta is definitely not perfect- not yet- but it is very stable and very compatible with existing software. If you want to start working with Windows 7 beta, you will not experience any significant problems using it with Telerik’s tool. You can confidently develop on Windows 7 beta with all of Telerik’s tools and you can confidently deploy applications to Windows 7 beta built with Telerik’s components.

Don’t count our support as “official” yet- we’ll wait for Windows 7 release versions before dubbing our support official- but hopefully this overview will help you know what you can expect if you start working with Win7 early. And in short, you can expect good things when comes to Telerik and the Windows 7 beta.

The many localizations of RadEditor and RadSpell

Todd Anglin — Thu, 05 Feb 2009 21:37:57 GMT

Did you know that there over 25 localized versions of RadSpell's dictionaries (30, to be exact)? Did you know there are over 10 localizations of RadEditor? When you're building a global site, you often need to support a number of languages, and thanks to Telerik's outstanding community, we are able to offer a huge range of localizations for the RadControls- especially those controls which depend heavily on localized strings. Not all controls require localizations- a RadSlider or ColorPicker, for example, communicate their UI without any built-in strings. Even controls like RadGrid don't have much need for localization. Other controls- like RadEditor, RadSpell, and RadScheduler- have more built-in UI elements with string values and thus more need for broad localization support.

Officially, Telerik supports three languages:

English (en-EN)
French (fr-FR)
German (de-DE)

There are Telerik provided localized versions of the RadEditor and RadSpell dialogs for these languages, plus RadSpell dictionaries. Telerik has a large (and active) developer community, though, and many of our customers have shared their localizations for the benefit of the entire community. While not "officially" support, these localizations are made available by Telerik so you have easy access to huge variety of languages.

Beyond the "official 3," Telerik has RadSpell dictionaries for an additional 27 languages:

Arabic (ar-AR)
Afrikaans (af-ZA)
Bulgarian (bg-BG)
Czech (cd-CZ)
Danish (da-DK)
German (Swiss) (de-CH)
Spanish (es-ES)
English (Australian) (en-AU)
English (British) (en-GB)
English (Canadian) (en-CA)
Italian (it-IT)
Hebrew (he-IL)
French (Canadian) (fr-CA)
Hungarian (hu-HU)
Norwegian bokmål (nb-NO)
Norwegian nynorsk (nn-NO)
Dutch (nl-NL)
Polish (pl-PL)
Portuguese (pt-PT)
Portuguese (Brazil) (pt-BR)
Romanian (ro-RO)
Russian (ru-RU)
Ukrainian (uk-UA)
Slovak (sl-SK)
Swedish (sv-SE)
Slovenian (sl-SI)
Thai (th-TH)

All localized dictionaries are available on the Telerik forums. Of course, community submitted dictionaries may not be as complete as the Telerik provided dictionaries, but we hope that these resources help. For RadEditor, there are localized versions of the dialogs and toolbars in these 9 languages (beyond the "official 3"):

Danish (da-DK)
Dutch (nl-NL)
English (British)
Hebrew (he-IL)
Italian (it-IT)
Japanese (ja-JP)
Polish (pl-PL)
Portuguese (Brazil) (pt-BR)
Traditional Chinese (zh-DN)

You can download these global resources on the Telerik forums, too. In the same zip resources, you also find some "bonus" localizations. There are a few localizations for RadScheduler, RadUpload, and RadProgressArea in the following languages:

English (British) - RadScheduler, RadSpell (dialogs), RadUpload, RadProgressArea
Hebrew - RadSpell (dialogs), RadUpload, RadProgressArea
Portuguese (Brazil) - RadScheduler, RadSpell (dialogs)

Hopefully these resources will come in handy for your global projects that use the RadControls. And if you've got a localization of the RadControls not listed here, why not share it with community! Send Telerik an email with your localizations and if we're able to use them, your efforts will be happily rewarded. 'Til next time, Goodbye! Auf Wiedersehen! Arrivederci!

Optimization Tips: RadInput vs. RadInputManager

Todd Anglin — Thu, 29 Jan 2009 15:04:00 GMT

In the Q3 2008 release, Telerik introduced a new control to the RadControls for ASP.NET AJAX suite called RadInputManager. Like RadInput, it is designed to enable you to provided textboxes to your users that give real-time validation and feedback based on the entered text. The big difference with RadInputManager, though, is that you don't have to add lots of Telerik Input controls on your page to get this real-time feedback. Instead, you can quickly convert "standard" ASP.NET TextBoxes to RadInput textboxes via the RadInputManager configuration- similar to how you can use RadAjaxManager to quickly ajaxify your page without littering it with UpdatePanels.

RadInputManager is a very innovative control and- in my opinion- one of the biggest steps forward in simplifying ASP.NET form validation to come around in a long time. In this optimization tip, we'll take a look a the RadInputManager (RIM) control to see how it simplifies form validation and see how it helps us improve page performance.

SIMPLIFYING FORM VALIDATION

When ASP.NET developers want to validate form inputs today, that usually represents the beginning of a time consuming task where form validation controls are add to the page for every input that needs to be validated. After the assorted RequiredField, RegularExpression, and Range validators are added, their prosperities set, and some type of UI added to display their error messages, you're left with a page cluttered with markup that is unrelated to the actual layout or function of the form. Further, any complex validations on the page are usually set such that they do not get evaluated until the form has been submitted, meaning users get feedback regarding their input errors long after the mistake has been made. Not great for usability.

With RadInputManager that all changes. Instead, validating form inputs becomes easy and painless:

You add standard ASP.NET TextBoxes to your form where you want to collect values
You configure RadInputManager to apply RegularExpression, Numeric, DateTime, or RequiredField validations the appropriate textboxes
You run the page

No markup littering. No need to set properties over and over again on controls that are providing the same validation. And as a bonus, when you use RadInputManager, users get real-time feedback when their input does not validate, enabling them to correct it before submitting the form.

RADINPUTMANAGER VALIDATION TYPES

We won't go in to fully detailing the RadInputManager's properties- there are great docs available for that- but I will highlight it's capabilities as a form input validation control. Via the control's simple configuration properties, you can accomplish any of these validations:

Numeric - only accept numeric digits, specify Max and Min number range, specify negative number formatting, specify decimal formatting
Date- specify allowed DateTime format, specify allowed DateTime range
RegularExpression- specify any regular expression to validate
TextBox- use as simple RequireField validator

In addition to these specific validation types, RadInputManager allows you make any textbox required (essentially replacing the need for separate required field validators) and it enables any textbox's validation to be declaratively connected to a web service for powerful server-side validation. With a single control, you're replacing the need for separate TypeValidators, RangeValidators, RequiredFieldValidators, and CustomValidators for every input on your form.

RADINPUT VS. RADINPUTMANAGER

RadInput has been part of the Telerik RadControls for quite some time and- like the RadInputManager- it provides rich, validated text input. In fact, the RadInputManager is really just simplifying and optimizing the creation of RadInput controls on your page. Rather than manually adding a RadInput every place you need input validation and then initializing all of those controls separately, RadInputManager allows you to simplify the the configuration and optimize the initialization on the client. For example, if you needed to validate 5 numeric textboxes on a form, you might do this with RadInput:

ASPX

<telerik:RadNumericTextBox ID="RadNumericTextBox1" runat="server" MaxValue="100" MinValue="0"> </telerik:RadNumericTextBox><br /> <telerik:RadNumericTextBox ID="RadNumericTextBox2" runat="server" MaxValue="100" MinValue="0"> </telerik:RadNumericTextBox><br /> <telerik:RadNumericTextBox ID="RadNumericTextBox3" runat="server" MaxValue="100" MinValue="0"> </telerik:RadNumericTextBox><br /> <telerik:RadNumericTextBox ID="RadNumericTextBox4" runat="server" MaxValue="100" MinValue="0"> </telerik:RadNumericTextBox><br /> <telerik:RadNumericTextBox ID="RadNumericTextBox5" runat="server" MaxValue="100" MinValue="0"> </telerik:RadNumericTextBox><br />

Notice the duplication of properties we have to set for each control. Also note that if we want to change the validation in the future, we have to replace the entire input control. With RadInputManager, the same configuration might look like this:

ASPX

<telerik:RadInputManager runat="server" ID="radInputManager1"> <telerik:NumericTextBoxSetting MaxValue="100" MinValue="0"> <Validation IsRequired="true" /> <TargetControls> <telerik:TargetInput ControlID="TextBox1" /> <telerik:TargetInput ControlID="TextBox2" /> <telerik:TargetInput ControlID="TextBox3" /> <telerik:TargetInput ControlID="TextBox4" /> <telerik:TargetInput ControlID="TextBox5" /> </TargetControls> </telerik:NumericTextBoxSetting> </telerik:RadInputManager>

Where in the above code snippet I have "TextBox1" through 5 somewhere on my form. Now I'm only setting my validation rules once, and I even have the ability set the "IsRequired" flag (something not available with RadInput). If I need to change the validation of a TextBox in the future, it's a simple matter of defining a new "Validation Setting" in my RadInputManager and adding the TextBox to its "TargetControls" collection.

IMPACT ON PERFORMANCE

When you use RadInputManager instead of RadInput, you're optimizing your page in two ways:

1) You're reducing the bytes sent over the wire
2) You're reducing the page initialization time

To observe this, we'll create a simple test that is made-up of two pages: one page has 40 RadInput controls (10 of each flavor, Numeric, DateInput, MaskedTextBox, and TextBox) and the other 40 standard TextBox controls with RadInputManager (configured with 10 controls for each setting type, Numeric, Date, RegEx, and TextBox). We'll load both of these pages in FireFox six times (on an empty cache each time) and measure total bytes received, JavaScript bytes received, HTML bytes received, requests, and average page load time. We'll then compare the numbers to see the relative difference (not absolute, since absolute times are impacted by many factors) RadInputManager has on page performance.

As a follow-up, we'll also re-run the tests- both with RadInput and RadInputManager- with the RadManagers to see how they affect overall page performance.

Bytes Over the Wire

This chart shows us the difference in bytes sent over the wire when using RadInput vs. RadInputManager for the exact same scenario (40 inputs). I did not include the results of the tests with the RadManagers because they do not significantly effect the bytes sent to the client (in this test, they only reduced total bytes by about 1%). What we see right away is that RadInputManager reduces the total bytes sent to the client by about 22%, but it sends about 5% more JavaScript to the client than RadInput. To achieve he overall reduction, RadInputManager is sending much less HTML- about 55% less in these tests. That's significant for one very important reason:

When a page is requested, all page resources (like JavaScript) will be cached and the cached versions will be used on subsequent page loads. The HTML, however, will be requested and sent every time the page loads.

So while RadInputManager does send slightly more JavaScript, those resource gets cached on the initial page request and then the lightweight HTML gets exchanged after that. With RadInput, you're passing twice as much HTML for every page request.

Average Page Load Time

When it comes to page load time, we also see a significant gain in performance with RadInputManager. Since the Manager can coordinate the initialization of the validation logic (as opposed to having 40 separate controls trying to initialize on page load with RadInput), overall page load time can be reduced. In these tests, the page with RadInputManager took an average of 23% less time to load than the page with RadInput controls. Page load performance was even better when the RadManagers (RadScriptManager and RadStyleSheetManager, for the unfamiliar) were added, extending RadInputManager's benefit to about 27% less loading time while cutting total requests in half (from 11 to 5).

OPTIMIZATION TIP SUMMARY

RadInput and RadInputManager are two very capable input validation controls. Both have features that make them compelling- such as RadInput's support for numeric "spinners" and RadInputManager's support for RequiredFields- so it's important to pick the right control when designing your pages. For richer UI with more interactive controls, RadInput is currently your best choice. For top performance and highly optimized pages, RadInputManager is the best choice for a few simple reasons:

It reduces the bytes sent over the wire and has a better caching story
It is much faster to configure than RadInput or traditional ASP.NET validation controls
It improves overall page load performance

Hopefully the evidence presented in this article will help you understand the benefit of using RadInputManager in your own projects and show you yet another way Telerik is trying to deliver more than expected when it comes to helping you optimize your web applications.

Optimization Tips: RadCompression Module

Todd Anglin — Wed, 28 Jan 2009 17:19:39 GMT

Welcome back to the ongoing Optimization Tips series. It's been a while since the last installment, so it's high-time we took a look at more tips and tricks for optimizing your Telerik-powered web applications. In this the seventh article in this series, we'll take a look at Telerik's brand new RadCompression HttpModule and try to gain a deep understanding of how this tool can help improve application performance. Some of the concepts in this article build on things we've discussed in previous installments, so I encourage you to read the earlier articles before reading this if you have not already done so. Let's get started.

WHAT IS RADCOMPRESSION?

Simply put, RadCompression is a HttpModule that ships with the RadControls for ASP.NET AJAX (Q3 2008 SP2 and later) that is designed to automatically compress your AJAX and Web Service responses. In other words, RadCompression will intercept the bits that your server is sending back to a browser (or Silverlight-client, for that matter) and compress them. Once the compressed bits reach the browser, standard browser technology takes-over and decompresses the response so your application can work with it normally. The compression process is completely transparent to your client-side code (JavaScript or Silverlight) and your server-side code. It simply reduces the number of bits that must be sent over the wire (from your server to your client) and thus- in theory- improves your page performance by reducing the TTLB (time to last byte).

WHAT RADCOMPRESSION IS NOT

RadCompression is not designed to be a complete replacement for other HTTP compression tools, such as the built-in HTTP Compression in IIS 7. Instead, it is designed to work with those existing tools to cover scenarios they usually miss- namely the compression of bits moving back and forth in AJAX (and now Silverlight) applications. If you have HTTP Compression enabled in IIS7, you'll discover that it does not compress your AJAX and Web Service responses; it only compresses the initial bits sent to the browser when the page is requested. By adding RadCompression to your project, you cover those gaps and start compressing your XHR (XmlHttpRequest - i.e. the "X" in AJAX).

So, if RadCompression does not cover all HTTP traffic, what does it cover? Quite simply, RadCompression will automatically detect and compress requests that expect these content response types (as found in the HTTP request's "ContentType" header or "AcceptsTypes" header):

application/x-www-form-urlencoded
application/json
application/xml
application/atom+xml

These types generally reflect the content types returned by AJAX Web Services, ADO.NET Data Services, and AJAX UpdatePanel responses, though there certainly are other scenarios that return these content types (such as a typical RSS feed). If a browser supports compression (and most modern browsers do), and RadCompression is enabled, all content of this type will be compressed. The one exception is IE6, which does not well support this compression, so RadCompression will automatically ignore requests coming from IE6 clients.

HOW DO YOU ENABLE RADCOMPRESSION?

Enabling RadCompression really couldn't be easier. It's a simple matter of adding a HttpModule registration to your site's web.config. Specifically, you need the following:

XML (Web.Config)

<httpModules>
  ...
  <!-- Add this line exactly as is - the name value is important --> <add name="RadCompression" type="Telerik.Web.UI.RadCompression" /> </httpModules> <!-- If you're using IIS7, then add this, too--> <system.webServer> <modules>
      ...
      <add name="RadCompression" type="Telerik.Web.UI.RadCompression" /> </modules>
...

With that single line of configuration (or two lines if you're using IIS7 Integrated Pipeline), RadCompression is ready to work. You don't need to make any additional code or configuration changes. The compression module will automatically look for content that matches the conditions mentioned above and compress it. Remember that HttpModules, unlike HttpHandlers, touch every request processed by ASP.NET, so you don't have to do anything to your pages or services to make the compression work. All compression is handled by the module. All decompression is handled by the browser.

WHAT IS THE BENEFIT?

Time to get down to the brass tacks. Does RadCompression really help improve your application's performance? As you know, in the Optimization Series, we've been testing different optimization techniques and their effect on page load time. It's crude, but it gives you a relative idea of how the technique can improve your application's performance. For RadCompression, I ran eight unique tests, executing each six times to collect a reliable sample set. The tests are composed of two distinct scenarios:

1) UpdatePanel Updates: In this scenario, there is a page with a RadGrid, bound server-side during the NeedsDataSource RadGrid event, with a RadAjaxManager on the page to "ajaxify" all Grid operations.

2) Client-binding Updates: In this scenario, there is a page with a RadGrid that is declaratively bound to a ADO.NET Data Service (which, for the unfamiliar, is essentially a fancy WCF web service). The RadGrid fetches data via the service and initializes in the browser and uses the web service for all operations, such as paging.

For both scenarios, the data layer is a simple LinqToSql model using the AdventureWorks database. Both grids are bound to all Employees in the AdventureWorks data store, so the scenarios should be equal except for the way they handle initial data binding and binding for operations like paging. For each scenario, we'll test the following, measuring bytes sent during the request, bytes sent in the response, total requests, and page load time:

Initial page load
Paging the RadGrid with RadCompression disabled
Paging the RadGrid with RadCompression enabled
Loading and paging the RadGrid with RadCompression + the RadManagers (RadScriptManager, RadStyleSheetManager)

These tests will show us the relative impact of adding RadCompression to a site. Let's take a look at the results:

Average Bytes Received

This chart reveals some interesting facts. First, we see that choosing to use UpdatePanels (and server-side binding) or client-side binding does not significantly initial page load size. In fact, it takes a few more bytes to start with client-side binding (though we see when the RadManagers are used those bytes compress better). The real benefit of the client-side binding is revealed in the RadGrid paging operations, where the bytes received are reduced by 62% (on average). When we add the RadCompression HttpModule, we see improvement in both scenarios paging scenarios. With UpdatePanels and "traditional" AJAX, bytes sent over the wire are reduced by about 68% with RadCompression enabled, and by about 86% with client-side binding. So right away we see that RadCompression has a significant impact on reducing traffic for async operations like paging in RadGrid.

Average Page Load Time

The load time results can be a bit confusing at first. They are not nearly as dramatic as the reduction in bytes received, so you have to look close to understand what's happening. First of all, we can see that all operations- including the initial page load- are happening in less than one second. In fact, all of the paging operations are happening in about 1/10 of one second! That means the localhost environment makes it hard to see the impact of the compressed bytes on page load time while paging a RadGrid. You can see, of course, that the RadManagers help reduce the initial page load time by about 25%, but the RadCompression module has a negligible impact on the RadGrid paging load time. The take away: for sites deployed to a local network (i.e. intranet sites), you really don't need to worry about performance optimizations at the level RadCompression provides. The latency is low enough and the bandwidth high-enough that you won't see a significant impact on page load performance. For remote sites, though, the delta between load time with and without RadCompression should be much more obvious (thanks to the time required to transfer 75% more bytes over the wire).

OPTIMIZATION TIP SUMMARY

When it comes to RadCompression, the impact it has on your site just depends on where your users are located. If you have a site that is deployed over the web, where latency and connection speeds are unpredictable, reducing the bytes you send over the wire is an easy way to improve your site's performance. And since RadCompression can literally be implemented with a single change to your config file, you really don't have much to lose. In a quick word:

RadCompression is an easy way to reduce the bytes sent over the wire for XHR operations.

Hopefully you'll enjoy this new tool in your Telerik toolbox. Whether you use them or not, Telerik is working hard to give you all of the tools you need to optimize your websites with very little work. When combined correctly for the right sites, we believe we can enable you to not only to build sites quickly, but with measurable top performance.

Simplifying OpenAccess Scope in ASP.NET with HttpModule

Todd Anglin — Tue, 20 Jan 2009 17:11:27 GMT

Whenever you start working with a modern ORM tool, one of the biggest challenges is figuring out how to manage the "scope" (or sometimes called "context" or "data context"). It is this transactional space where the ORM tool keeps track of changes being made to "persistent objects" in your application so that they can be saved to your "persistence layer" (usually a database) when you're ready to commit them. But figuring out when to create a scope, when to close it, and all the annoying problems that result from closing a scope too early can be very frustrating, and they often are what drive people back to the "raw" ADO.NET they know.

So let's simplify that process for OpenAccess. I'll show you how you can use a HttpModule to automate the management of your OpenAccess scope in ASP.NET applications.

SCOPE <> DATABASE CONNECTION

If you remember one thing, remember this: an open scope does not equal an open connection to your database. It was this fact that really helped the proverbial light bulb go-off inside my head when it comes to understanding scope management. The scope is an in-memory object related to tracking changes you're making to your persistent objects. Leaving a scope "open" for the duration of a HTTP Request is not going to leave a connection to your database open for the same period of time. Rather, a scope will automatically open- and then quickly close- connections to your database when operations requiring interaction with the persistence layer are executed.

That means it is okay to create a scope at the beginning of a request, and then dispose of it at the end of a request. In fact, doing so will help us avoid a lot of errors that can creep in to a ASP.NET project when scope is closed early (like the dreaded "IObjectScope is already closed" errors).

HTTPMODULE FOR SCOPE

What programming mechanism does ASP.NET provide for interacting with every HTTP request? The HttpModule (HttpHandlers only respond to requests with specific extensions, making Modules the better choice here). The basic approach to our module is this:

On request start, create a new ObjectScope and store it in Session
Use stored Scope in application code (accessing from Session)
On request end, close and dispose ObjectScope

That sounds easy enough. There is a catch, though. Session is not available in the HttpModule BeginRequest event (it's null). So how then will we store our new Scope in Session? We'll use the less known PreRequestHandlerExecute and PostRequestHandlerExecute events, which fire just before and just after the page event handlers are executed. To use the events, we'll wire them up in our Init method:

public void Init(HttpApplication context)
{
    //Wire-up Pre and Post RequestHandlers
    context.PreRequestHandlerExecute += new EventHandler(context_PreRequestHandlerExecute);
    context.PostRequestHandlerExecute += new EventHandler(context_PostRequestHandlerExecute);
    
    //Get the defined session "keys" from the Web.Config string key = ConfigurationManager.AppSettings["OpenAccessScopeKey"];
    string transKey = ConfigurationManager.AppSettings["OpenAccessTransactionKey"];
    string commKey = ConfigurationManager.AppSettings["OpenAccessCommittableKey"];

    //Use the keys from Web.Config, or if null, use default values
    SCOPE_KEY = key ?? "objectScope";
    TRANSACTION_KEY = transKey ?? "transactionScope";
    COMMITTABLE_KEY = commKey ?? "committableKey";
}

In addition to wiring-up our events, we also grab a few values from our web.config that will be used to store our scope in Session. This config-based keys approach makes it easy to use the same key in both our HttpModule and our application code and reduces the "brittleness" of the code that would be introduced by hard-coded values.

Next, we need to actually write code for the Pre and PostExecuteHandler events. In these events, we need to create and dispose our scope, respectively. The code we need is pretty simple:

void context_PreRequestHandlerExecute(object sender, EventArgs e)
{
    //Verify that the HttpContext Session is not null if (HttpContext.Current.Session != null)
    {
        //Create a new object scope and save it in Session
        HttpContext.Current.Session[SCOPE_KEY] = ObjectScopeProvider1.GetNewObjectScope();

        //Create new transaction for the scope
        CreateTransaction();
    }
}

void context_PostRequestHandlerExecute(object sender, EventArgs e)
{
    //Verify the HttpContext Session is not null if (HttpContext.Current.Session != null)
    {
        //TEST HELPER: Use this setting to make all transactions rollback //thus preventing any data from changing in the DB if (ConfigurationManager.AppSettings["OpenAccessRollbackAll"] != null &&
            ConfigurationManager.AppSettings["OpenAccessRollbackAll"] == "true")
            RollbackTransaction();
        else
            CommitOpenAccessTransaction(); //Commit the open transaction

        ObjectScopeProvider1.Database().Properties.TransactionProvider = TransactionProvider.OpenAccess;
        //Dispose the open Transaction object
        DisposeTransaction();

        //Clear session variables (remove items from session)
        ClearSessionValues();
    }
}

As you can see, when the request starts, we're simply using the ObjectScopeProvider class (a class provided automatically by the OpenAccess wizards in Visual Studio) to create a new ObjectScope and then we save it in Session. At the end of the request, we commit any open transactions (unless we're in "test rollback" mode), dispose our scope and transaction objects, and then remove all values from Session. Now, when we want to write code in our application, we can simply use the Scope stored in session and not have to worry about opening or closing a scope manually in our application code. In fact, we can even improve the ObjectScopeProvider class in our web projects to look for an existing scope in Session automatically, like so:

static public IObjectScope ObjectScope()
{
    //If Scope found in session, cast and return it if (HttpContext.Current.Session != null && HttpContext.Current.Session[ConfigurationManager.AppSettings["OpenAccessScopeKey"]] != null)
        return (IObjectScope)HttpContext.Current.Session[ConfigurationManager.AppSettings["OpenAccessScopeKey"]];

    //If no scope found in session, return new Scope
    Database();

    if( theObjectScopeProvider1.myScope == null )
        theObjectScopeProvider1.myScope = GetNewObjectScope();

    return theObjectScopeProvider1.myScope;
}

ISN'T SESSION A BAD THING

Normally, and in many cases, yes, especially when you're faced with taking an application in to a multi-server environment. But in this case, since we're only using session for the duration of a single request, we're not faced with the same problems. We add our Scope to Session on the start of a request, use it for all OpenAccess processing in that request, and then close it and remove it from Session when the request is done. That means we don't care if the next request goes to a different server, because the process will start over and a new Scope will be created and destroyed.

Could you leave your Scope open longer than a single request? In theory, yes, but that does introduce some rather tricky scenarios that you'd have to handle in your application, such as how to handle "orphaned" Scopes that do not get closed by some application event. So for web applications, opening and closing a Scope once per request is usually the safest and easiest to manage approach.

And that's all there is to it. I'm attaching to this post a sample C# project that contains my implementation of the OpenAccess HttpModule for managing Scope. To use it, simply add the project to your solution, and then reference it in your OpenAccess-enabled web project. Don't forget to register the HttpModule in your web.config, too:

XML (Web.Config)

<httpModules>
  ...
  <add name="OpenAccessScopeModule" type="TelerikOpenAccess.Data.Module.ScopeHelper, TelerikOpenAccess.Data.Module" />
  ...
</httpMoules>

Hopefully this will help simplify your OpenAccess web projects and help make the process of managing Scope almost invisible.

Download OpenAccess Scope HttpModule (VS 2008 C#)