Todd Anglin's blog

dotNetRegister: Requirements

anglin — Tue, 26 Aug 2008 17:22:10 GMT

Before we can begin any serious coding of the recently introduced "dotNetRegister" reference app, we need to define some some requirements. As with any good agile development effort, I want to create a backlog of features that need to be implemented and then prioritize development from there. I even intend to work on this application in sprints, though clearly, as a part time project, I don't expect to have a stellar burn-down rate.

ASIDE: If any of these agile terms- like backlog, sprint, or burn-down rate- are unfamiliar to you, I highly encourage you to spend a little time becoming more familiar with agile development. Agile is an excellent way to manage many projects, not just development projects (in theory, you could do "agile honey-dos"), so it's well worth your time to understand its core concepts.

To begin defining our functional requirements, let's first establish the scenarios we want our v1 dotNetRegister to support:

Exhibitor Registration- We want our system to intuitively support any event that needs to collect registrations from companies that will be exhibiting at the event (usually in a booth). We want this process to be very flexible, though, so the exhibitor registration should also support sponsorship options. In fact, maybe sponsor registration should be spun-out in to its own process since many events have sponsors that do not exhibit. We'll have to keep this in mind as we refine what our exhibitor registration process should like; for now we'll make sponsor processing part of exhibitor registration.
Attendee Registration- We want our system to optionally support attendee registration for events. Many events, like code camps, conferences, and job fairs, require that attendees register before arriving. Attendee registration is often as simple as an RSVP process, but for larger conferences it's a complete process that requires payment processing. We need our system to be configurable enough to handle this range of scenarios.

If we build a system that is flexible and configurable, with easy to use front-end registration tools backed by simply powerful admin management tools, we should have a system that is capable of handling everything from college job fairs to code camps to shows like TechEd. To help provide some focus for early development though, I will focus on serving the needs to two particular use cases:

Job Fairs (my domain expertise)
Code Camps (different enough from job fairs and a good target user for our system)

Beyond our primary scenarios and use cases, at high level we also want our system to be able to:

Process credit card payments (with a configurable architecture for plugging-in different payment processors via configuration files)
Support a "sandbox" mode (for easy regression and integration testing)
Pass the Mom Test (many organizers of events are non-tech people and we want the system to be as intuitive as possible for them)
Run in .NET 2.0 + ASP.NET AJAX or .NET 3.5 environments (including shared hosting)
Be quickly configured (via config files for basic app settings and interactive wizards for event setup)
Support multiple clients (that means web services- we want to be able to have mobile and client UIs to manage our data)
Support multiple simultaneous events (a single system should be able to process registrations for multiple events)
Track event history (in other words, be able to "instance" events for historical reporting)

That's a good place to start for now. There are many, many more specific functional requirements for the system, but we'll start here. In my next update, I'll build and explain several use cases that will support our application design process. And once we have our use cases, we finally move-on to creating some code. In the mean time, let me know what you think of these requirements. Would you like to make sure the system covers other specific scenarios? If so, share your ideas in the comments and we'll use those to refine our initial requirements.

dotNet Register: An Intro

Todd Anglin — Thu, 31 Jul 2008 22:09:00 GMT

One of the tasks that has been on my "to do" list for quite some time now is to build a big, real world-ish application that not only provides value to the community but also shows-off a lot of the RadControls in action. It's a big task and one that's especially hard to tackle when traveling about the world to speak and preparing smaller demos that work well in "small bites." But I'm putting my foot down and committing to begin work on this big project now!

The goal of my "big project"- which, by the way, still needs a cool code name- is to build an open source-ish (it'll be using Telerik UI controls, so it won't be completely open source) .NET event management application. Actually, I'll be re-building an application I originally built before I joined Telerik called CareerFair LIVE. CareerFair LIVE, which is still alive and well today and supporting a number of college career fairs, is a hosted online application (SaaS, if you will) that provides colleges with a complete platform for running job fairs. The system collects company registrations, handles credit card payments, generates reports, has built-in HTML email campaign support, and a number of other tools that are essential to running a job fair. I'll provide more history on the roots of Cfair LIVE in future posts, but the point is it's a "real world" application that uses many of the RadControls and it's how I first met Telerik.

For this new iteration, I want to make an application that is even more generic and flexible; one that can handle many different event types (other than career fairs), such as smaller tech expos, huge trade shows, and community events like summer camps. Basically, anything that requires a registration process. To help limit the scope for my first efforts, though, I'll be focusing on making the system flexible enough to support job fairs (my area of domain expertise) and tech expos (an arena that I think can benefit from better tools). Other specific implementations will come with time or community involvement.

Part of the success of CareerFair LIVE was our ability to keep the tools "simply powerful." In other worlds, enable users to accomplish many tasks without needing a lot of training or technical expertise. I want to build applications that pass the "Mom Test." Telerik's latest RadControls for ASP.NET AJAX are going to make that possible. I also want to extend this application beyond ASP.NET AJAX, providing support for UIs like the iPhone in the mobile space and WFP touch-screen in the desktop space. Ultimately, I want this to be the best .NET event registration application available.

The basic architecture will look something like this:

I've picked NHibernate for my ORM tool to keep this as open source as possible, but in the future I may change the ORM data layer to show how a well structured application can make (relatively) easily a seemingly difficult change. I'll be using PayPal as the primary payment provider because it's simple to interface with and something I'm familiar with (I am a Certified PayPal Developer, after all). Development on this new project will start soon, and as soon as I have something meaningful, I'll try to get it hosted on CodePlex. From there, I'd love to get your feedback! I'm a UI guy- I think at the interface level- so I'm no great application architect, but I know many of you are great application architects. So, if you're interested in contributing to the project once it gets going, let me know so I can get you involved.

There will be many more posts that this project generates as I relay to you the challenges and triumphs of the development, but ultimately the goal is to provide an outstanding reference app that will be deployed in real world scenarios that you can use to maximize your Telerik learning. Stay tuned for the fun and feel free to send me your ideas!

Optimization Tips: Optimizing Custom Skins

anglin — Tue, 24 Jun 2008 17:37:08 GMT

Welcome back to my ongoing series on optimizing the Telerik RadControls for ASP.NET AJAX. For those that are counting, this is the fifth installment in the series, so if you've missed the first four parts I suggest you go back and read them now. This article builds on some of the concepts we've covered previously, so a sound understanding of the earlier concepts is a plus. And before you get confused, you won't find the other installments on blogs.telerik.com. Up to now, this series has been running on my popular Telerik Watch blog, but going forward all installments will be published here. Capice? Good. Let's get down to business.

In this installment we are going to take a look at custom skins, specifically how to build them and how to optimize them for performance. With the latest release of the RadControls for ASP.NET AJAX, we can not only optimize the built-in skins for performance but also any custom skins we build. And since many "real world" applications require custom skinning, understanding how to optimize those skins is a handy trick. Let's take a closer look.

Creating a custom skin

Before you can talk about optimizing a custom skin, first you have to build one. For this article, we're going to build and optimize a custom skin for RadTabStrip, but the approach used can be generally applied to any of the RadControls. Creating a custom skin basically consists of three steps:

1. Copy an existing skin
2. Modify the skin with your desired CSS customizations
3. Set properties on RadControls to use your custom skin

First, you copy an existing skin to establish a baseline that you can easily customize. You could, of course, build a skin completely from scratch, but that approach is significantly more difficult. Copying one of Telerik's eleven included skins (every skin exists for every control) is by far the best way to begin your customizations. To build my custom skin, I copied the Default skin for RadTabStrip.

Next, with your copied assets in a new App_Themes folder, it's time to start customizing. For simple customizations, you may only have to change some CSS. If you're after a very custom skin, though, you'll probably need to break out the Photoshop (or similar...though I'd always recommend Adobe tools for design) and build some custom images to use in your skin. These images are usually used to compose the background of your skin and they usually include variations for each state of the control (unselected, selected, hover, selected hover, etc.). My custom skin includes two image files- one for the tab backgrounds and one for the optional Tabstrip scroll buttons- but these images encapsulate all of the control's states. How? CSS Sprites.

Maximizing Skin Optimization: CSS Sprites

We need to pause for a second and talk about CSS Sprites. Using sprites to optimize image files is not an invention of the Internet era. Back in the day, video game designers would use sprites to save all of the graphical icons needed in a game as a way to conserve space (this was before game designers "needed" 50 GB to build a game) and improve performance. The concept: it is easier to load a single image file in to memory and reposition it to display the relevant data instead of loading and unloading many individual image files.

On the Internet, the optimization effect takes on an even greater level of importance. What is one of the most common bottlenecks on web pages that hurts page load performance? Concurrent connections to the web server. Modern browsers can only download a handful of items from the same domain at one time (usually 2 - 4 connections), which means pages with tons of images, CSS files, and JavaScript files take an exceptionally long time to download- not because of the bits, but because of the connection limit. The best (but not only) way to solve the problem is to reduce the number of items a page must download (in other words, reduce the requests).

The RadManagers we looked at in part one of this series do just that for CSS and JavaScript, but even they cannot automatically optimize images. To do that, we rely on sprites. Rather than requiring over 10 image files to build a Tabstrip skin (first tab, first tab selected, tab, tab selected, last tab, etc.), we can build a complete skin with a single image. The single image contains all necessary states and we use CSS to correctly position the background image for each tab. And while it can be a little tricky to understand how to build sprite image files at first, the improvement they provide in page load time makes them well worth the effort.

Back to the article

Okay, now that you understand what CSS sprites are and why they are important for building highly optimized skins, let's take a look at the sprite I built for my custom skin. You can see in the image below that my single image file contains all of the states I'll need in my Tabstrip skin. The size of this PNG file: less than 8 KB.

It looks strange at first, but when the CSS is applied, this image produces a RadTabStrip that looks something like this:

Don't worry if you still feel overwhelmed or if CSS sprites still seem confusing. I am providing the original Photoshop file used to build this custom skin at the end of this article, which should help you get an even better grasp on this process. But for now we need to move on.

Assuming you've built your skin, debugged your CSS, and everything is looking good, the last step is to apply your custom skin to your RadControl. This requires that you set two properties: EnableEmbeddedSkins and Skin. Set the first property, EnableEmbeddedSkins, to False. This tells the RadControl to look for external skin elements instead of using the Telerik-built embedded skins. By default, the RadControls will look in App_Themes > SkinName > ControlName to find the external skin, where "SkinName" is the value you set the Skin property to and ControlName is the name of the control (like TabStrip, Editor, Grid, etc.). With that, your control is ready consume your custom skin. To easily add references to your skin elements on the page, set the Page's Theme to the name of the Theme folder that contains your custom skin.

See a live preview of the custom MidnightArrow skin

Super optimizing your custom skin

So you've built your custom skin, applied it to your RadControls, and everything is working great. But then you read my article on the RadManagers and were stoked about the page load performance gains those controls provide when using the built-in RadControl themes. "That's cool," you thought, "but I've got to use custom skinning. Is there any help for me?" Absolutely.

By taking the following steps, you can enable any custom skin to work with the RadStyleSheetManager, which means your custom skins can be automatically optimized with the rest of the RadControls on your page. Here's what you need to do:

1. Create a new Class Library project in your solution
2. Copy your skin CSS file and supporting image files to your new solution
3. Add WebResource references to your skin elements in the default class file
4. Mark all skin elements in your solution as "EmbeddedResources"

What you're doing is building a custom assembly to hold your custom skins. The RadStyleSheetManager can only optimize your skin if it is available as an embedded web resource, so you're adding you skin elements to an assembly that the RadStyleSheetManager will consume. I won't go in to the full details of how this process works in this article, but there is a great tutorial on Telerik.com that shows you exactly what to do. Follow that article that build your custom assembly.

Once your assembly is ready, reference it in your web project and configure your RadStyleSheetManager to use it. You must be using RadControls for ASP.NET AJAX Q1 2008 SP1 (2008.1.515) or later for this technique to work. To use my custom skin for RadTabStrip, I set the following in my RadStyleSheetManager:

<telerik:RadStyleSheetManager runat="server" ID="styleManager">
    <StyleSheets>
       <telerik:StyleSheetReference Name="TelerikCustomSkins.TabStripMidnightArrow.css"
           Assembly="TelerikCustomSkins"></telerik:StyleSheetReference>
   </StyleSheets>
</telerik:RadStyleSheetManager>

In the previous snippet, "TelerikCustomSkins" is the name of the assembly I built to hold my custom skins and "TelerikCustomSkins.TabStripMidnightArrow.css" is the path to the "TabStripMidnightArrow.css" file in my skins project. With these settings in-place and the properties I previously configured still set (EnableEmbeddedSkins=false, Skin=MidnightArrow), my RadTabStrip is ready to use my highly optimized custom skin.

The performance comparison

You now know how to build your custom skin and how to super optimize it with the RadStyleSheetManager, but is the effort worth it? Let's let the numbers talk. The following graph shows the comparison in page load times and number of requests on page load for an identical page, one with a RadTabStrip using my custom skin in the App_Themes directory, one with a "super optimized" version of my custom skin.

Clearly, the optimization benefits of reducing the requests on the page by enabling your custom skin to work with the RadStyleSheetManager are clear. Skins optimized to work with the RadStyleSheetManager helped reduce page load time on average by almost 10% and reduced the number of requests on page load from 8 to 7 (initial request + 3 for ASP.NET AJAX JS, 1 for Telerik JS, 1 image, 1 for CSS). And this is for a simple page with one custom skin. You can expect the benefits would exponentially increase for more complex pages using several custom skins. Exponentially because as you add more custom skins to optimized pages you'll keep adding extra requests for CSS whereas super optimized skins will always generate a single CSS request.

Optimization Tip Summary

The summary of this tip is pretty easy:

If you're using custom skins with the RadControls for ASP.NET AJAX, you need to "super optimize" them to work with the RadStyleSheetManager to maximize your page load performance.

Hopefully you found this overview of skinning and skinning optimization helpful. There are a lot of other great skinning resources on Telerik.com, including full guides for skinning all of the RadControls in online documentation. Use the information in those articles along with the tips you learned here to ensure your skinning is as optimized as possible and your pages load as quickly as possible. Until next time, have fun optimizing your apps and impressing your developer friends with your mad coding skills.

Download the Photoshop source file

Download MidnightArrow RadTabStrip custom skin

I'm back online - Another blog to follow

anglin — Fri, 30 May 2008 15:49:38 GMT

Hello all! It has been quite a while since I last posted on the official Telerik Blogs. The reasons and excuses range from technical problems to unbelievable busyness, but I won't bore you with them here. What is important is that I've restored my connectivity to the Telerik Blogs and I fully intend to begin making regular updates here in the future. If you purged this blog from your feed readers in my absence, be sure to re-add it so you won't miss a thing.

In the mean time, while I haven't been active on these blogs, I haven't been absent from the blogging world! In fact, I've been quite busy regularly updating Telerik Watch, my "official" ASP.NET weblog, and even writing full articles for sites all over the Net. In fact, right now I'm engaged in a series on Telerik Watch covering performance optimization tips for the RadControls for ASP.NET AJAX. If you're interested in following that series, here are some quick links to catch you up:

Watch Telerik Watch for installments after we get back from TechEd. Until then, enjoy the Optimization Series and have a fun (and safe) weekend!

How To: Format RadGrid PDFs

Todd Anglin — Wed, 19 Sep 2007 03:01:00 GMT

On Monday, I showed you some the new settings in RadGrid 5 the enable you to control certain aspects exported PDFs. We looked at how you can easily set the PDF's metadata, change its filename, and even control the PDF's security settings. All of these settings- along with the ability to force the PDF to open in a new window- can be set with a single property in the Grid's new ExportSettings configuration block. What we didn't look at on Monday is how you can control the formatting of your exported PDFs. Today we'll take a look at how you can customize the styling of the Grid rendered to the exported PDF.

One thing should be clear before we begin: the RadGrid styles that you see in the browser (the Grid's skin) will not directly render to the PDF when the data is exported. The Grid's PDF rendering mechanism does not support styles contained in external stylesheets. Rather, the rendering mechanism requires that styles be rendered inline with the Grid's markup to be properly conveyed to the PDF format. And that's the code we'll take a close look at in this post.

For our discussion today, let's say we have a page with a single RadGrid and ASP.NET button. When the button is clicked, we want to export the data from our Grid to a PDF. Simple enough. The markup for that page might look something like this:

When this page is rendered in the browser, we'll see the button and the RadGrid with it's cool new default skin:

But when we click the "Export" button, the grid in our PDF looks like this:

Clearly, we need to add some styles to our PDF grid. To do that, we'll need to add some code to our page that applies custom CSS styles to the RadGrid when the "Export" button is clicked. These styles will not be displayed on the page; they will only be applied to the exported PDF. For today's demo, I am going to work on changing the header style of my RadGrid. You can apply many standard CSS styles to your Grid's cells when exporting to PDF, but not all styles will be rendered. I'll try to provide a complete list of styles that do not affect the rendering of the PDF in a future blog post. For now, let's look at the simple code that is required to apply my styles:

The key to this code is the "ApplyStyleToPdfExport" method that I've created. This method accepts a GridTableView (which will be the MasterTableView from our RadGrid) and then applies some settings to the Grid's header. The basic format for applying style rules is:

gridItem.Style["<css property>"] = "value";

Where "gridItem" is the item from the GridTableView you want to style and "css property" is the style setting you want to apply. One of the biggest limits at the moment seems to be the inability to change the PDFs font with this approach, but as soon as I find a workaround I'll update this post. Other than that, you can set these styles just like you would if your were styling the Grid manually for display on a page.

With our new styling code ready, when the "Export" button on the page is clicked the exported PDF now looks like this:

Quite an improvement! Okay, it's not that dramatic, but you get the idea. And that's all there is to it. With these basic concepts in hand, you can style your exported RadGrid data to your ~~heart's~~ client's content.

First Look: RadGrid 5 PDF Export (updated)

Todd Anglin — Mon, 17 Sep 2007 09:02:00 GMT

By now you probably know that one of the biggest new features in RadGrid 5.0 is support for export to PDF. For quite some time, RadGrid has supported direct export to Microsoft Word and Excel formats, but the addition of PDF export elevates the Grid's exporting capabilities to unprecedented levels. Using the new export feature couldn't be easier. As with previous export formats, all that is required is a call to a single simple RadGrid method:

this.RadGrid1.MasterTableView.ExportToPdf();

When you call this method, all of the data in the Grid is exported to a new PDF that the users can then save to their local file system. The PDF is saved in a format that is compatible with Adobe Acrobat Reader 4.x and higher and by default uses the file name "RadGridExport.pdf". If you do not like this name, you can change it in the new RadGrid ExportSettings section. This section gives you control over a number of PDF and general export parameters, such as:

FileName: change the file name of the exported file
ExportOnlyData: indicates if links and other basic HTML will be preserved on export (CSS styling will not be exported)
PDF Specific Settings:

Author: sets PDF metadata author value
Creator: sets PDF metadata creator value
PaperSize: sets PDF paper size
PageTitle: sets PDF page title (rendered on top of page)
Title: sets PDF metadata title value
Keywords: sets PDF metadata keyword value
AllowPrinting/Add/Copy/Modify: indicates if users have permission to print/add/copy/modify exported PDF

There are more settings available for controlling RadGrid exports, but the basic point is that you have a fair amount of control over your exported documents. You don't have total control, though, so don't expect RadGrid to provide the same level of formatting that you can find in Telerik Reporting. Exporting data to PDF from RadGrid will not preserve the Grid's skin. Data will be rendered without any of the CSS styling you see in the browser and will use only the default font settings. You cannot control the PDF's font size, color, face, or other formatting settings. You essentially get to set the page size, margins, and metadata and then let RadGrid do the rest. For more advanced exporting, you'll need to check out Telerik Reporting.

Still, if you've been dying to offer PDF export to your users for RadGrid-based data, this is an amazing feature. It works without any trouble right out of the box and doesn't require any special coding or web.config changes. This should be a great feature for anyone looking for a "poor man's" reporting solution or the flexibility to export data in a universally readable format.

For comparison's sake, here's how RadGrid 5.0 exporting compares to other grid products on the market:

*Supports RTF export

As you can see, the new PDF and CSV export formats in Q2 make RadGrid the most flexible ASP.NET grid for exporting available. Check out RadGrid 5.0 for ASP.NET in Q2 2007 and have fun with the new PDF export!

UPDATE/CORRECTION: It turns out that you do have some control over the PDF formatting when exporting from RadGrid. The export command will not render any external stylesheet styles (a.k.a. Skins) to the PDF, but it will render any inline CSS rules applied ot the Grid. That means skins are still out and that you're going to have to do some extra work to style your PDF, but it can be done. Watch for a future post showing you how to add inline styles to RadGrid and format your PDF.

RadEditor Prometheus up to 76 percent faster

Todd Anglin — Thu, 30 Aug 2007 04:12:00 GMT

For months now we have been talking about the new RadEditor being built in the "Prometheus" suite and how it is going to be the best version of RadEditor to date. Today an early preview of that work was released in the "Prometheus" Futures build and made available for general testing in the Telerik community. Obviously, the version that was released today looks a lot different from the final version that will be released- dialogs are still rough, features are unpolished, and some features are missing- but it is still a great look at what's coming.

Today I ran the RadEditor Futures release build through some tests to compare the total page load time to the current Q2 2007 SP2 RadEditor. While the exact feature sets of the two controls differ at this stage, I tried to configure the classic Editor with the only the controls in the default "Prometheus" Editor to make the tests fair. To measure the page load times, I turned to the handy JavaScript page load stop watch I blogged about many months ago. I ran each control- Classic and Prometheus- through 12 tests: 6 in FireFox 2, 6 in IE7, 3 with "unprimed" browser cache, and 3 with the component's files already cached by the browser.

The results were amazing!

RadEditor "Prometheus" on average loaded 76% faster in IE7 after the control's files had already been cached. It loaded 67% faster on an unprimed cache. The gains in FireFox are more modest, but the load time has still been cut almost in half. Overall, IE7 loads both versions of RadEditor faster than FF2, but the difference in performance is much greater with RadEditor "Prometheus". IE7 on average loads RadEditor "Prometheus" 56% faster than FireFox, compared to a mere 13% advantage with the classic Editor component. I expect FireFox's performance to approach IE's in future RadEditor "Prometheus" builds.

Out of curiosity, I compared "Prometheus" Futures RadEditor to another leading WYSIWYG web editor to see how their performance compared. The other editor loaded quickly- faster in some tests by tenths of a second. At first I was a little stunned. Then I compared more closely the feature set and richness of this competing control. It completely lacked innovative user interface features like the integrated RadWindow for dialogs (it just uses clunky browser windows) and basic features like undo history (not to mention lack of Ajax support or an extensive client-side API)! When you consider the extra features and richness RadEditor "Prometheus" delivers in 3 tenths of a second, I think the delay becomes acceptable for most users.

Either way, the number one rich-text editor on the web is definitely getting faster in version 8 and any applications that use RadEditor should definitely plan of upgrading soon after Q2!

Ultimate .NET Credit Card Utility Class

Todd Anglin — Thu, 30 Aug 2007 01:04:00 GMT

Have you ever thought about processing credit cards in your .NET application? If you have, then you know one of the first things you need to do is find some code to validate that credit card numbers entered by your users appear correct before you send them along to your payment processor. Having created applications in the past that process credit cards, I know that this task can be surprisingly harder than it should be. There are plenty of code snippets scattered across the 'Nets that show you how to do individual parts of the validating process, but there are few resources that pull of the code together into simple, easy to use utility class. Until now.

I have written and posted an article on the Code Project that presents the Ultimate .NET Credit Card Utility Class. This utility class, provided in both C# and VB with NUnit tests and a test website, has everything you need to quickly start pre-validating credit card numbers before you initiate a transaction with your payment processor (sometimes referred to as your "Gateway"). Hopefully you'll find this class helpful in your projects and it will save you some time when you're ready to start accepting credit cards. If you have some ideas on how to improve the "ultimate" utility class, leave your ideas in the Code Project article forums and I'll be sure to update the project.

Enjoy!

View Ultimate .NET Credit Card Utility Class article

How to: Create RadRotator Programmatically

Todd Anglin — Mon, 27 Aug 2007 03:11:00 GMT

It recently came to my attention that there is no good documentation on the Telerik website showing you how to create a RadRotator (with a defined template) programmatically. There is some documentation out there showing you how to programmatically data bind a RadTicker, and the RadControls Learning Guide has some good guidance, but nothing exists online for easy Rotator reference. Let's solve that problem and take a quick look at how you can programmatically create your RadRotator and template.

Step 1: Define your template
Defining a template for RadRotator in code is very similar to the process involved in programmatically creating a template for RadGrid. Basically, you just need to create a class that implements ITemplate and that renders controls where you want them. The complexity of your template class depends entirely on how many controls you render and how many of them need to be data bound, but with basic knowledge you can scale the principles involved to handle any situation.

In today's demo, we want to create a RadRotator in code that rotates through a collection of images. To do that, we need to create a template class that renders an Image control and bind the ImageURL to our data source. The basic shell of our template will look something like this:

To begin working with our new class, we can use Visual Studio's helpful template implementer by right-clicking on "ITemplate" and selecting "Implement interface", like this (C# only, VB will automatically implement the interface if you hit the tab key after adding it):

After you select "Implement Interface", Visual Studio will automatically add the methods to your class that need to exist for you to completely satisfy the interface's contract. Each method stub will also contain a "throw" statement that will cause an exception if you do not manually add some logic to each method's body. With the interface implemented, our class now looks like this:

Now we need to add some "real" code to the InstantiateIn method. This is were we define and layout the controls that we want to display in our template. In this demo, we simply need to add a single Image control, but you could anything here (like new tables, divs, server controls, etc.). For completeness, we'll render our Image control in an HTML div, producing code that looks like this:

Nothing in this code should be too tricky, but the important line to look at in more detail is the DataBinding. Here you define a new EventHandler that will fire whenever the template needs to bind your control to your RadRotator's data source. Every control that you add to your template that needs to be bound to data needs to follow this same approach. The data binding method for this demo will look like this:

Here's where things get a little more specific to RadRotator. Notice in the above code snippet that we have to get a reference to the RadRotatorFrame that contains our data bound Image control. To do that, we reference the Image control's NamingContainer and store it in a local variable. With the reference to the RotatorFrame in hand, we finally have access the the DataItem for the current Rotator frame that we can use to data bind our control. The DataItem type depends entirely on your data source. If your RadRotator data source is an array of strings, the DataItem will be of type String. If the data source is a DataTable, your DataItem type will probably be DataRowView. This is an important thing to keep in mind when working with a Rotator programmatically and databinding to different data source types.

Step 2: Define your RadRotator
Now that you have a programmatic Rotator template defined, the next (and final) step is to define your RadRotator. This is usually done in a page's PageLoad method, but you can do it wherever you're defining the controls that should be rendered at runtime (if it's a WebPart, for instance, this may be the CreateChildControls method). You can define a wide range of properties when you create your Rotator, but for this demo we'll accept most of the control's default settings and focus on the code that is required to data bind our control. In the PageLoad method, we'll add the following code:

You can see that we set the FrameTemplate property to a new instance of our RadRotatorTemplate to define our Rotator's template. If you are binding to a data source that requires dynamic input in the template (such as column names), you can add code the RadRotatorTemplate constructor to accept those values and make them available to the class' data binding methods. In this case, our data binding is simple and we simply create an array of image paths in the "CreateRotatorData" method:

And that's it! When you run your page, the RadRoator will be displayed and the template area will bind controls in each Rotator frame to your data source. In general, that means one frame will be rendered per "row" (or entry) in your data source.

With this simple example, you should be able to confidently add RadRotators via code anywhere you need them and no longer feel constrained to design-time only solutions. If you want to see another example of creating templates programmatically, check out page 584 in the RadControls Learning Guide. The Learning Guide example binds the Rotator to a DataTable, so it is a good next step if you're comfortable with the code in this demo.

Download demo project in C#
Download demo project in VB

XhtmlPage: What does it do?

Todd Anglin — Tue, 14 Aug 2007 03:31:00 GMT

Have you ever been working with the Telerik Quickstart examples and wondered why all of the demo pages inherit from XhtmlPage instead of System.Web.UI.Page? Even if you guess that this custom base page somehow ensures that all rendered demo pages are XHTML valid, have you ever wondered how the base page manages to deliver that functionality? In this post, we'll take a close look at the XhtmlPage class and see what it's doing to deliver easy XHTML validity. The lessons learned from this class can easily be applied to your own custom page classes and used to make your web sites as accessible as possible.

XHTML Compliance

Before we look at how XhtmlPage delivers XHTML validity, it is important to understand why XHTML validity matters. And frankly, for many websites, XHTML does not matter. But for those sites where accessibility and standards compliance are paramount (such as government sites, large corporate sites, or nitpicky hobby sites), delivering XHTML compliance is not an option; it's a requirement.

XHTML in the simplest sense is just well formed HTML. It exists as the convergence of HTML and XML and is essentially a strict subset of standard HTML markup. Most (if not all) modern browsers are very forgiving, silently rendering improperly tagged HTML (such as missing closing tags, missing attribute quotes, etc.). While this makes it easier to create web pages and reduces the chances the browser can't render a page for a user, it does mean developers can unknowingly render mal-formed HTML to the browser. The end effect is that the rendering results of a page are not consistent from browser to browser depending on how the browser tries to "fix" your HTML.

In theory, XHTML should also require less processing power and time to render since it can be predictably parsed (like XML). In practice, though, few browsers deliver XHTML support that surpasses the HTML rendering capabilities- even on mobile platforms- so the benefits of XHTML are more theoretical than practical. Still, if you can make your pages XHTML compliant, it definitely ensures you'll be rendering HTML that is compliant with WC3 standards.

RenderChildren

At the heart of the XhtmlPage class is a single overridden method called RenderChildren. This method is responsible for rendering all of the page HTML on the server and is the perfect place to examine rendered HTML and modify it to our heart's desire. In this case, we want to inspect the rendered HTML, look for any possible XHTML violations, and fix them before the rendered page is sent to the client.

This method begins by executing the standard System.Web.UI.Page RenderChildren method to obtain the page's HTML output. Once in hand, our overridden method calls six additional methods that work on the HTML output to look for XHTML problems: FixEmptyTitleTag, FixAutoPostBackElements, RemoveScriptLanguageAttribute, FixFormNameAttribute, FixDoPostback, and FixViewState.

FixEmptyTitleTag

This first step in the XHTML compliance process uses regular expressions to find any <title> tags on the page that contain the word "Untitled" or have no inner content. If the RegEx parser finds a match, it removes the matched portion of the document. The result is a page that renders without a <title> tag if it is empty or untitled.

This fix is more for convenience than actual XHTML compliance. XHTML 1.1 guidance does require a page <head> tag to contain a <title> tag, so this check will actually break XHTML compliance if the <title> tag is empty. It will, however, prevent any pages from displaying the unsightly "Untitled Page" title. Compliance can easily be delivered if a simple title is added to the page.

FixAutoPostBackElements

The second step in the process looks for the "language" attribute in any HTML elements on the page that can be used to trigger auto postback events. If the RegEx parser finds any input or select elements on the page, it removes the language attribute and re-inserts them into the page's output string. The language attribute is optional, and in valid XHTML the attribute should be "lang" instead of "language". In this case, it is easier to remove the optional attribute than to try to fix it.

As with all RegEx operations where we are trying to remove blocks text, we use named backreferences (a regular expression concept) to capture portions of our matched text into accessible variables. By using a RegEx MatchEvaluator, we can evaluate our named references and reassemble a string without a specific match block, like this:

RegEx Match definition (backreferences highlighted)

Match evaluator putting "beforeLanguage" and "afterLangauage" sections together

RemoveScriptLanguageAttribute

The third step towards XHTML validity inspects the HTML output for any <script> tags with the language attribute set to "javascript". If any matches are found, the RegEx evaluator will remove the language attribute, ensure the <script> tag has the required "type" attribute, and then return new <script> tag markup to the page output. For XHTML compliance, the "type" attribute is required, but specifying the language is optional. It is easier to remove the optional tag than to perform extra work to ensure the tag is properly formed. As with PostBackElements, if the language is specified in a XHTML document the attribute should be written as "lang" to be valid.

FixFormNameAttribute

The next step evaluates the page's form tag and removes the "name" attribute if it exists. In XHTML, the "name" and "id" attributes (both of which exist in HTML) serve the same purpose of identifying an object on the page. XHTML 1.0 sought to simplify the processing of documents by requiring only the "id" attribute for identifying objects. It also formally deprecated the "name" attribute. To make our ASP.NET rendered form tag valid, we remove the deprecated "name" attribute and add the valid markup back to the building output string.

FixDoPostBack

By default, ASP.NET PostBack JavaScript tries to reference the page form by its "name" attribute. This is a problem since we just removed the "name" attribute in the previous method to deliver XHTML compliance. To bring everything back together, we need to use RegEx to look for PostBack JavaScript and replace code that references the form by its name with code that references the form by its id. That will make our page XHTML compliant (no "name" attribute in the form tag) and it will preserve the ASP.NET PostBack functionality.

FixViewState

Finally, one of the more commonly acknowledged XHTML problems caused by ASP.NET is the rendering of the ViewState hidden field. The ViewState hidden input is rendered directly to page, not in a XHTML required containing element. Actually, the problem exists for all of the hidden fields rendered by ASP.NET, like __VIEWSTATE, __EVENTARGUMENT, __EVENTTARGET, __LASTFOCUS, and __EVENTVALIDATION. To fix the problem, the hidden elements must be placed inside of plain HTML DIV tags, which can easily be done using our RegEx evaluators.

Extending this solution

Clearly, the XhtmlPage solution delivered in the Telerik Quickstart demos does not address all possible XHTML problems on a page. For example, XHTML requires that all tags and attributes are written in lowercase letters and that all attribute values are quoted. It also requires that singleton controls (like <img /> and <br />) are properly closed. Depending on how much control you have over the content added to your page (CMS systems, for example, have unpredictable content), stealing processing power to do these extra compliance fixes may or may not be worth the effort.

The XhtmlPage solution aims to address the major XHTML compliance problems introduced at the ASP.NET framework level. Most of these fixes target the XHTML 1.1 document type definition (DTD), which means the fixes may or may not cover the validity of page that uses a different XHTML DTD.

Wrapping it up

Hopefully this brief look at the XhtmlPage class helps clear up the mystery of the demo's custom base page and introduces you to the process of making your pages XHTML valid. Creating a custom base page for your web sites offers numerous benefits, not the least of which is providing fine control over the page's rendering. With a little RegEx magic and careful planning, you can easily make your site XHTML valid and run it through the XML validators without a problem.

RadControls on iPhone: Part 3

Todd Anglin — Fri, 27 Jul 2007 04:12:00 GMT

In our final look at the RadControls for ASP.NET running on an iPhone, we'll look at RadSplitter, RadTabStrip, RadToolBar, RadTreeView, RadUpload, and RadWindow. In the first two installments of this series we looked at the other 12 RadControls running on the phone and found most of them to be usable or semi-usable. So far, only RadEditor has earned an unusable rating on the iPhone's mobile Safari. Today we'll pass judgement on the remaining RadControls and then create a quick summary chart that you can reference during your future iPhone development.

So without further delay, here's how the final six controls fared:

RadSplitter: Semi-usable
RadSplitter on an iPhone produces some pretty varied results. Depending on how the the Splitter is configured, it can work almost perfectly or it can become practically unusable. The basic features of RadSplitter work in most cases, with simple content correctly displayed in nested splitter panels and expand/collapse buttons working as expected. Dragging to resize splitter areas is obviously out of the question on the iPhone, and (like other controls) scrollbars fail to render when content exceeds the size of a panel area. But unlike other controls, when content length exceeds a splitter panel area it is not simply hidden out of view. Rather, the "extra" content spills out of the RadSplitter control and is visibly rendered on the page. The behavior makes it impossible to load external content correctly and is one of the major failures of the RadSplitter on an iPhone.

That said, if you use simple RadSplitter implementations, it can work on the iPhone. For that, RadSplitter earns a semi-usable rating, though the emphasis here is definitely on the semi.
RadTabStrip: Usable
RadTabStrip works exceptionally well on an iPhone. It's very responsive, easy to use with the touch interface, and renders single- and multi-row tabs without error. The only noticeable problem with RadTabStrip on the iPhone is vertically aligned tabs. For some reason, this alignment does not render properly in mobile Safari. Other than that, it's a very safe control to use in your iPhone targeted applications.
RadToolBar: Usable
Not to sound repetitious, but RadToolBar also performed very well on the iPhone. Aside from some small rendering problems on image + text buttons, the control looks good and is easy to use. RadToolBar is not a particularly complicated control, though, so this result should come as no surprise. As with all things designed for the iPhone, good implementations of RadToolBar should use larger buttons than would normally be used in a web application to make it easy for people to "click" without zooming.
RadTreeView: Semi-usable
Your success with RadTreeView on the iPhone will depend on how you want to use the control. As a read-only UI control, the TreeView works fine. You can easily expand/collapse nodes and click on nodes to navigate to new URLs (if being used as navigation). If you dig a little deeper, you can also perform tasks like checking nodes, but it can be challenging to do with the touch interface. For more advanced operations, though, like editing nodes or dragging-and-dropping nodes, the iPhone interface breaks down. Dragging and dropping is clearly a limit of the phone's interface, but the problem with editing a node is less clear. You can get a node to transition into edit mode, but it immediately reverts to read-only mode after you complete the click-to-edit.

Given the poor optimization for the iPhone and the inability to use many of the TreeView's more advanced features, RadTreeView earns a semi-usable rating. But unlike RadSplitter, the emphasis is on usable.
RadUpload: Unusable
You probably saw this one coming. As you may know, the iPhone does not allow you to access its filesystem unless you've joined the thriving iPhone hacking community. Based on that restriction, mobile Safari seems to automatically disable the browser's file selection objects- the core of the RadUpload control. So aside from the basic functionality of RadUpload being disabled by the browser, the control does still render properly. Visitors to a page with a RadUpload control on an iPhone will be presented with a good looking, functionless control.
RadWindow: Semi-usable
We've mentioned RadWindow several times throughout this three part review since there are several other RadControls to use RadWindow to present dialogs. Therefore, you already know that RadWindow does work at a basic level on the iPhone. It can be loaded on the page, minimized, restored, closed, and refreshed. It can display most content types, including external sites, but the scrollbar limitations still exist with this control. If the content is too large for a RadWindow, it will automatically (and uncontrollably) expand vertically to display the content. Content that is too wide for the RadWindow will simply be inaccessible. The modal RadWindow dialogs partially work, but for some reason the text on the modal dialog buttons does not display on the phone.

Regardless of these results, RadWindow is not a control that is designed for easy use on a device like the iPhone. It is unlikely that you'll want to include this control in iPhone targeted applications if you can avoid it.

Summary Wrap-up
So there we have it: all 18 RadControls running on the Apple iPhone. Overall the results are pretty good, and compared to any other cell phone-based browser they're incredible. Mobile Safari on the iPhone is definitely not the exact same Safari that runs on Windows and OS X, but for the most part it renders HTML and process JavaScript identically (though the JavaScript processing is much slower). It's the iPhone's unique input mechanism- and the related limits it imposes- that cause most of the "problems".

For quick reference, here are how all of the RadControls performed on iPhone 1.0:

Happy RadControl coding on the iPhone!

View the final RadControls on iPhone image gallery

RadControls on iPhone: Part 2

Todd Anglin — Wed, 25 Jul 2007 06:07:00 GMT

In part one of this three part series, we looked at RadAjax, RadCalendar, RadChart, RadCombobox, RadDock, and RadEditor running on the iPhone. We found most of those controls run relatively well on the iPhone with the exception of RadEditor. In this second installment, we'll look at another batch of RadControls and pass judgement on their usability. Each control will be deemed either usable, semi-usable, or unusable on the iPhone so that you can quickly tweak your applications (or build new ones) for iPhone users.

Today's lucky controls are RadGrid, RadInput, RadMenu, RadPanelbar, RadRotator, and RadSpell. During all of my tests with these controls, the iPhone's browser never crashed. That is great news and a testament to RadControl's ability to run on a "light" browser like mobile Safari without crashing it. Now, let's see how each of these controls performed on the amazing device we all know as "the iPhone".

RadGrid: Usable
That's right. The flagship grid component from Telerik works pretty well on the iPhone's mobile Safari. All of the "read-only" features work flawlessly and the Grid renders without any problems. More advanced features like paging, sorting, hierarchy, filtering, and even editing work, too. The only catch with the Grid on the iPhone is that some of the Grid's features are not well tuned for the "fat fingered" cursor. For example, it was very difficult to select page numbers precisely in paging demos and it took a few tries to get the filtering menu to display. The features work, they're just harder to use on the iPhone than on a regular computer. That said, many of these features could be tweaked with CSS settings and custom skins to adapt for the iPhone and improve the Grid's usability.

Among the features that didn't work were obvious iPhone no-no's like drag to reorder columns, column resizing, double-click to edit, context menus, and static header scrolling. Many of these problems exist due to the nature of the iPhone's input device, but some are simple shortcomings of the browser. Either way, the broken features are peripheral to RadGrid's core operation and it earns an "usable" rating on iPhone 1.0.
RadInput: Semi-usable
RadInput produced mixed results on the iPhone. The core functions of the Input control work, but behavior can be erratic at times. For example, trying to type a credit card number into a masked text box accurately prevented non-numeric characters from being entered, but it also only allowed one number to be entered at a time (you had to manually move the cursor position). Clearly a bad problem. Meanwhile, the date input control performed more normally, accurately highlighting an invalid date entry. Due to the varying results of these tests, I'd suggest you use caution when including RadInput in an iPhone targeted page.
RadMenu: Usable
No problems here. RadMenu performed flawlessly on the iPhone and should be safe to use in any application that targets the device. All skins rendered correctly and it was very easy to use the iPhone's touch-based interface to navigate and select menu options. There is one caveat, though, and that is "mouse hover" behavior. If your menu depends on hovering to expand its options, those options will not be available on the iPhone since there is no way to "hover" your finger. Instead, design "click to expand" menus for iPhone targeted applications and you'll have no problems.
RadPanelbar: Usable
Like RadMenu, RadPanelbar performed almost flawlessly on the iPhone. There were no rendering problems and everything from hierarchial panels to sliding panels worked correctly. The only feature that failed (as it has across the board on the RadControls) is scrolling. No scrollbars were rendered in the control when panels had elements that were out of view, so that is something to avoid. Other than that, RadPanelbar is another safe tool to use in your iPhone development toolbox.
RadRotator: Semi-usable
RadRotator works, but it is plagued by the iPhone's slow processing of JavaScript animations. All RadControls with JavaScript animation run much slower on the iPhone than on a normal browser, but the effect is more detrimental in RadRotator. Due to the slow animations, the Rotator's timing is erratic, causing frames to animate before tickers have displayed all of their text. That said, the problems can be all but eliminated if animations are not used or if very simple text content is all that is being rotated. The control's basic features and client-side events all work and function correctly, but the iPhone's handling of animations limits the usefulness of RadRotator.
RadSpell: Usable
This result may surprise you. Even though we discovered that AjaxSpellCheck does not work on the iPhone, the normal RadWindow-based RadSpell does! And surprisingly well at that. If you look past the fact that RadSpell's interface is far from optimized for the iPhone, you'll discover that everything is working. You can easily spellcheck any element on your page and use the RadWindow dialog to accept spelling suggestions and correct your work. The spellcheck dialog cannot be moved, though, due to the iPhone's inability to handle drag and drop interactions. Users must move the dialog into view and work with it where it loads on the page. And while I definitely wouldn't recommend using RadSpell on an iPhone due to the poor UI optimization for a touch-based interface and low resolution screen, it does work. If you have an application that uses RadSpell, you can rest easy knowing it will work for your iPhone users, too.

All told, it was another successful outing for the RadControls on the iPhone. At this point, there are only a few controls to avoid on the iPhone (RadEditor, RadCombobox, and RadInput), making your RadControl toolbox for iPhone development quite large. Check out the full gallery of this round of testing to see all of controls in action and stay tuned for the final installment with the remaining RadControls later this week.

RadControls on iPhone: Part 1

Todd Anglin — Mon, 16 Jul 2007 03:32:00 GMT

Love it or hate it (as those seem to be the only two options), the iPhone is here and there are already over a million people using it to surf the "real Internet" in their pockets. And if there is anything I love more than ASP.NET and the RadControls, it's gadgets. So naturally I had to replace my "so last season" BlackBerry 8300 with an 8GB iPhone soon after it came out (which, for those that care, I love and fully recommend).

One thing Steve Jobs and Apple stressed during the marketing blitz leading up to the iPhone's release is that the phone would use Safari to browse the web. Since Telerik's RadControls are supported in Safari, I was very eager to give them a try on the phone to see how well they'd perform on the mobile platform. I had done similar tests on my BlackBerry- both with the BlackBerry Browser and the Opera Mini browser- and the results were miserable.

In short, the RadControls perform admirably on the iPhone. Their performance is not perfect, and some controls work better than others, but compared to other mobile platforms the iPhone is a leap ahead. In this series, I'll look at each RadControl on the iPhone and let you know if it's usable, semi-usable, or unusable. Each installment will also be fully supported by a picture gallery that I'll post and narrate with comments.

In part one we'll look at six RadControls: RadAjax, RadCalendar, RadChart, RadCombobox, RadDock, and RadEditor.

RadAjax: Usable
RadAjax is completely usable on the iPhone. Since this is more of a communications component than a UI component, there are no photos to directly demonstrate this in the gallery, but it definitely works without a hitch. You can safely use RadAjaxPanels, RadAjaxManagers, and AjaxLoadingPanels in applications that are accessed by the iPhone or in applications that are specifically designed for the iPhone's interface.

This is one of more exciting results since Ajax-based development is the only way to put custom "applications" on the iPhone (for now). There have already been some very compelling Ajax apps created for the iPhone, such as JiveTalk for iPhone, but Telerik's framework can help you create your own Ajax apps for the device in no time at all.
RadCalendar: Usable
This result slightly surprised me since the RadCalendar component takes advantage of some complex CSS, DHTML, and JS to make its magic happen. It seemed to be no problem for the iPhone, though, as I was able to use the DatePicker and the fast year/month change functions of RadCalendar without issue. The only caveat (as is true for most complex controls/sites on the iPhone at this stage) is that this control can crash the mobile Safari browser. It didn't happen to me during this test, but it has happened in the past. In general, the Safari browser on the iPhone it much more fragile than its big brother and still has some stability issues to work out.
RadChart: Usable
This result should come as no surprise. Most of RadChart's work is done on the server where the chart image is produced. Once you reach the browser, there is very little work that needs to be done to display a chart. As such, RadChart has no problem on the iPhone and can be used freely.
RadCombobox: Semi-usable
Here is a RadControl that you probably don't want to use if you're targeting the iPhone's browser. In a clear case of 'the iPhone Safari is not real Safari', you'll discover that many of the advanced features of RadCombobox do not work well. In fact, even simple things like displaying scroll bars when lists of options are longer than the drop down size present obstacles on the iPhone. Add to that the iPhone's unique handling of normal drop down lists, which use a fancy zooming technique to make it easy to select a drop down option, and RadCombobox clearly becomes a poor choice for drop downs on the device. If you have RadComboboxes in an application that may be accessed by iPhones, you will want to use a .browser file to feed the phone a different version of your page.
RadDock: Semi-usable
You may be surprised to discover that RadDock works relatively well on the iPhone. All docks seem to render without a problem and you can easily close, minimize, and expand docks on the screen. What you can't do (and this is no small issue) is drag or move DockingPanels on the screen. In fact, you'll discover that you can't drag and move any objects on the iPhone as the phone interprets these motions as trying to move the screen (the common method for navigating the device). So if you can tolerate not being able to move or reorder DockingPanels on the mobile version of your application, then you can use RadDock without concern. If you need drag and drop functionality, don't expect to find it anywhere on the iPhone.
RadEditor: Unusable
Before I explain why RadEditor is unusable on the iPhone, let me start by sharing a few features that are usable. On the iPhone, the Editor and its toolbars render correctly and all Editor content renders correctly, too. You can even use the toolbar buttons and invoke the many Editor features without error (including the RadEditor file managers). What you can't do is edit the content of the Editor (thus my rating). No matter what you do, clicking in the Editor's content area does not bring up the iPhone's keyboard thus enabling you to edit the content. If you can't perform the "edit" function of a control named "RadEditor", I consider that unusable.

If you're using RadEditor as a read-only control, then have no fear. Your applications will still work fine in their read-only context. It's only when you try to use the RadEditor to edit content that the short comings become apparent.

Check out the full gallery of photos that show the RadControls in action on an iPhone. I'll cover another batch of RadControls later this week and then we'll finish-up the series early next week. Until then, get busy developing applications for the "overwhelmingly happy" iPhone users using Telerik's RadControls.

Working with Zip Files: Part II, Zipping Files

Todd Anglin — Thu, 12 Jul 2007 23:45:00 GMT

In part one, we looked at how you can use RadUpload and the open source SharpZipLib to easily upload and expand zip archives. Today, we'll look at the other end of the process: creating new zip files on the server and then making them available for users to download.

To do this, we'll extend the sample we created in part one. As you recall, our sample already enables users to upload a zip file that contains image files and then the server automatically extracts all images to a target directory. We'll extend this demo by creating a text file and then zipping it up with our uploaded images. A link to download the new zip will be presented to our users when the zipping is done to complete the process.

Step 1: Identify files to zip
This step is very basic and may not be necessary if all of the files that you want to zip already exist on the server. To help demonstrate that the zip we're creating is not a copy, though, we'll create a new text file that lists all of the contents in our images directory. This text file will get wrapped-up with our images when we create our new zip archive in step 2. To create our simple text file, we'll use some code that looks like this:

Step 2: Create the new zip file
Just as there were multiple approaches to unzipping a file in part 1, there are different ways to use SharpZipLib to create a zip, too. We'll look at two approaches- the fast way and the manual way again- so that you can choose the method that works best for your projects:

Approach 1: Using FastZip
The FastZip class also contains a method for easily creating a zip file from a specified directory. The CreateZip method takes a few parameters and then easily zips an entire directory (with an option for recursive behavior that zips all sub directories, too) and saves the zip to the desired location. The code to do this is very simple:
Approach 2: Using the ZipOutputStream
For a more manual approach to creating your zip files, you can use the ZipOutputStream. Like the ZipInputStream we used to manually extract files from a zip, the OutputStream requires that we iterate through "ZipEntry"s and then use a FileStream to add file contents to the new archive. The following code will create a new zip archive with all of our target files:

One thing to note is that this code will not preserve our directory structure in the new zip (like the FastZip method will). To do that, we'd need to add some extra code (similar to what we did in part 1 unzipping demo) to create the necessary sub folders.

As you can see once again, creating new zip files is no harder than unzipping existing files. With the SharpZipLib and RadUpload tools in your .NET toolbelt, you can confidently approach projects that deal with zip files and have no problems working with the archives. To see these tools in action in a real world scenario, check out the new batch file converter on the Telerik Code Converter. We use the same general practices outlined in this series to enable people to upload zipped code for conversion and then download the results as a single zip file. Have fun working with zips!

Download sample code used in this article

Working with Zip files: Part I, Uploading and Expandning

Todd Anglin — Tue, 10 Jul 2007 01:45:00 GMT

Have you ever wondered how hard it would be to automatically zip and unzip archives with ASP.NET? It may be easier than you think thanks to the powerful SharpZipLib open source library. This library provides you with a number of easy to use tools for working with Zip (and GZip, Tar, and BZip2, for that matter) archives in .NET code that make the task of creating and expanding compressed archives relatively easy.

Today we're going to look at how you can use RadUpload and SharpZipLib to upload a Zip archive and then expand it on the server. For our scenario, let's pretend that we want to allow users to upload a zip with photos that we'll then automatically expand into an images directory. In future posts, we'll look at how we can do the inverse, taking files on the server and creating a new zip file that users can download.

Step 1: Setting up RadUpload
RadUpload has come a long way in its short revision history, and it is now very easy to just drop on your page and go. So we'll do just that- drag and drop a RadUpload control onto a page with a RadProgressManager and RadProgressArea that will be used to convey upload progress for larger file uploads. The markup should look something like this:

I've highlighted a few key properties on the RadUpload control that we've set here. First, we've set the MaxFileSize property to "102400" bytes (or 100 MB) to limit the upload size we'll allow. Next, we set the AllowedFileExtensions property to ".zip" to only allow zip files to be uploaded. We've also set the OnClientAdded property to the name of a JavaScript function on the page that will be used to make our file upload input boxes wider (more on that later). Finally, we set the CssClass of our regular ASP.NET button to "RadUploadButton" so that it will be automatically skinned by the RadUpload stylesheets. (Note: Visual Studio (2008 in this case) doesn't like my values in the ProgressIndicators property. This is a safe warning to ignore- the project will still compile and work correctly.)

When you use the progress tools, you do need to make some modifications to your Web.Config to handle file uploads larger than 4MB. These modifications tell the .NET runtime to allow the long requests necessary for a large file upload and they establish the HttpHandlers/Modules used by RadUpload control for large uploads. Three lines need to be added:

In the <httpHandlers> section, add:
<add verb="*" path="Telerik.RadUploadProgressHandler.aspx" type="Telerik.WebControls.RadUploadProgressHandler, RadUpload.Net2" />
In the <httpModules> section, add:
<add name="RadUploadModule" type="Telerik.WebControls.RadUploadHttpModule, RadUpload.Net2" />
In the <system.web> section, add:
<httpRuntime maxRequestLength="102400" executionTimeout="3600" />
Where maxRequestLength is the total file size allowed and executionTimeout is measured in seconds

Making file input textboxes wider
I mentioned that we would be making the RadUpload textboxes wider with the help of some JavaScript in the OnClientAdded client-side event. A full tutorial on the topic is available here, but the code that we're going to add to our page looks something like this:

This will make the invisible file upload controls (that cannot be styled) 54 characters wide. We'll edit the CSS in the skin for our Upload control to make the visible textboxes about 350px wide to match.

Step 2: Working with the uploaded Zip file
Since we're using the RadProgressManager to upload large files, we cannot simply access uploaded files through the RadUpload UploadedFiles collection. Instead, we need to access files via the ProgressManager's RadUploadContext, like this:

When using this approach, RadUpload will not save our files automatically. We need to call the "SaveAs" method for each UploadFile before it is available in the filesytem.

Now the important part: we need to unzip the file.

Unzipping the zip
There are two approaches we can take to unzipping the file when using the SharpZipLib: quick and easy or not as quick with more control. We'll look at both approaches so you can decide which works best for you. Before we do this, though, we need to add a copy of the SharpZipLib assembly to our bin directory (you can download the latest version here).

Approach 1: Quick and easy
The quick and easy approach utilizes the aptly named FastZip class in the SharpZipLib.Zip namespace. This class enables you to easily zip and unzip entire directories, but it does not easily enable you to evaluate every file before it is zipped or unzipped. So as long we don't mind unzipping everything in our archive, we can write code like this to do the job:

The FastZip.ExtractZip method takes a few arguments:
- Path to the zip file
- Path to unzip the files to
- Overwrite option
- File overwrite delegate (optional)
- RegEx directory filter (optional)
- RegEx file filter (optional)
- Boolean indicating if file time should be restored after unzip

The only thing tricky about these parameters that is not plainly obvious is that the filter properties specify what should be extracted, not what shouldn't. In other words, whatever your filter matches is what will be unzipped- everything else will be ignored.
Approach 2: Manually expand
If you do not use the FastZip approach, you can gain more control over the unzipping process by using the Zip class directly. This approach takes more code, but it will enable you to have exacting control over the entire unzip process:

You can see the basic process here involves accessing each file in the zip (referred to as "ZipEntry"s) and expanding it into a new file using a FileStream that reads the data out of the ZipEntry. You could inject any code you want in this process to filter unwanted files, change directory structures, or even resize files as they're unzipped.

Clearly, unzipping files with .NET is not that hard. With RadUpload to make the task of uploading large files a snap and SharpZibLib to make unzipping a no brainer, you can easily implement your own upload system that accepts zip files and expands them on the server. In our next installment, we'll look at how you can do the reverse- use SharpZipLib to zip files on the server and make them available for download.

Download sample code used in this article