Category Archives: 2009 R2

Server Side Paging in WebScheduler Timeline view

Performance and scalability are among our strongest focus in WebScheduler v3 release. Since Timeline view is capable to show a wide range of data (from minutes to quarters), loading all the data at once will significantly degrade the server and client performance and ultimately slowing down the application responsiveness in overall. The problem is even more noticeable when the loaded data is relatively huge and when Quarter view mode is used.

WebScheduler 3 addresses the performance bottleneck from top to bottom by introducing smart client paging (EventPageSize),  ViewPort paging, and server paging. The smart client and ViewPort paging are designed to provide paging solution for the client-side which dramatically improves user experiences. I’ve discussed the client paging features in my previous blog post.

In this post, we’ll learn the new server paging capability in WebScheduler 3, and how you can implement it in your application. Let’s take a clear and deep down look at it.


Designed to be an enterprise-ready scheduling component, we’ve added numerous new features in WebScheduler 3 to control the data retrieval mechanism. One of the most powerful features is server paging.

Server paging is an innovative feature built to eliminate sluggish performance due to the large data download while working in Timeline view mode. With server paging enabled, WebScheduler will download only a small chunk of data based on the viewport during initial load and intelligently requests more data as users scroll downward. This means reduced page load time and increased overall application responsiveness.

Not only that – you can also combine the server paging with smart client paging, JSON serialization and other features to boost your Scheduling application performance even more.

The following screenshot shows the WebScheduler with server-side paging enabled. Notice that it will load data on demand as needed.


Benchmark Result

To compliment this post with a more realistic performance comparison, I decided to do some simple testing and provided the screenshots that show the data and response time benchmark of server-side paging. In this benchmark, I’m using HighPerformanceScheduler sample which is included in the WebScheduler’s sample.

Also keep in mind that the HighPerformanceScheduler sample is using database with 3000+ records of events with 66 resources. All events are purposely recorded within 1 month to load test the WebScheduler performance in Timeline month view.

Using HttpWatch Professional 6.1, we can inspect the data size and the content returned from server. Notice that WebScheduler with server paging enabled loads only 176KB of data. That’s nearly 10x smaller when comparing it with server paging disabled which yielded 1553KB (1.5MB).

In addition, the server paging also significantly reduces data transfer time. For instances, assuming if you have 100kb/s internet connection, the load time with ServerPaging enabled will be done in approximately 1.7 seconds. Contrary, you will need to wait at least 15 seconds or more without ServerPaging.

The beauty of server paging is that it also keeps your browser light and responsive by rendering only a small amount of data at a time. Instead of loading all 3000 events at once, WebScheduler makes efficient use of resources by loading required events on demand when the page is scrolled downward.

You might be wondering how WebScheduler detects which data to be loaded in the next request. That is where smart client paging and ViewPort paging comes to rescue. To learn more on the new performance improvements in WebScheduler 3, please see the video below.


And here’s the best part. Taking advantage of this powerful feature isn’t rocket science – thanks to the WebScheduler’s bare-metal architecture. All you need to do is simply enabling the EnableServerPaging property in ViewSettings under the TimelineView property group.

Note: Server paging feature is only applicable when the client paging is set to ViewPort or Both. For certain scenarios with smaller data (less than a thousand of records in a month view), the server paging may not be necessary enabled so that the complete data can be transmitted in a single page load. In such scenarios, the client paging will perform data rendering immediately.

That’s all for now. I’d love to hear any comments, feedback or thoughts about this feature. Feel free to drop your comments here or post it to our forum.

Warm Regards,
Budianto Muliawan

Improve Page Performance in WebGrid When Used With WebMenuBar

Recently some customers reported that they experienced performance issue in their page which contains WebGrid along with WebMenuBar control. The issue is noticable when using Internet Explorer browser to view the page. After further research, this performance issue occured only when the Grid has AutoFitColumns property set to true while the WebMenuBar is using predefined styles that produced from the server-side settings.

Apparently, Internet Explorer has a serious flaw in performance when a script is trying to add styles programmatically while loading, and at the same time when layouting is performed by other scripts.

To eliminate the performance issue, all styles in WebMenuBar should be defined as CssClass instead of using server-side predefined styles.

For comparison, I have attached two samples (with and without CssClass). Run the samples and compare the performance difference between them.

Note: This technique also works on standalone WebToolBar which causes the same issue.

Support Engineer.

Customize Visible Hours in WebScheduler

One of the feature request we often received in the past is the ability to specify the visible hours in Day, Week, and Split views. By default, the hours in these views start from 00:00 to 23:59. You can now customize the visible hours to start and end at specific hours.

To customize the visible hours, simply specify the visible start hour using ViewSettings >> VisibleStartTime property and visible end hour using ViewSettings >> VisibleEndTime property. These configurations are applied globally, means Day, Week, and Split view will use the same visible hours.

The following screenshot shows scheduler that starts from 9 AM and ends at 7 PM. Note that work week styles are still applied at the specified hours.

visible hours

<ViewSettings SelectedViewMode="Week" SelectedDate="03/11/2008 10:00:00" 


Event rendering will be adjusted according to these settings. For example: the visible start time is set to 09:00 AM and visible end time is set to 07:00 PM. All events that fall within the date range will be rendered. Any events that start at 08:00 AM and ends at 10:00 AM will be rendered from 09:00 AM to 10:00 AM following the visible start time. The original duration of that event will not be altered; it can still be seen from the detail callout.

visible hours_event

The total of events that occur in a date is displayed as the tooltip of the date in the calendar area. When there is only one event that occurs in the specified date, the title of the event is displayed as the tooltip. When custom visible hours are specified, some events might not be included in the hour area. Although some events are hidden, users can still see the total of all events that occurs in the date in the tooltip of the date in the calendar area.

visible hours_calendar

If you have any feedback regarding this feature or you think this feature could be further enhanced, feel free to drop your comments or post your opinion in our forum. We’d be glad to hear them. Happy scheduling, everyone!

Virtual Group Paging with Client Binding – In Depth

As we’ve just released WebUI Studio 2009 R2 service pack, you can now download and try many exciting new features that we included in the release. Read more about the new release here.

One of the much anticipated new features is the virtual group paging capability that we shipped in the service pack, which I’ve discussed in my previous blog post. In this post, I’ll show you the step-by-step walkthrough to use the virtual group paging along with client binding in your application.

The following walkthrough presumes you have been familiar with the client binding and batch update feature that introduced in the initial WebGrid 7 release. To save time and space, this walkthrough will be focused only on the new group paging features. If you would like to see the walkthrough for client binding and batch update, please refer to WebGrid 7 online documentation.

Configuring WebGrid for Virtual Load and Group Row Paging

In this walkthrough, I’m going to use the ClientBinding_SmartBatchUpdate.aspx sample that shipped in the initial WebGrid 7 release. To work with the sample, launch the C# Samples which is accessible from WebGrid 7 program group in the start menu.

Once you got the sample ready in your Visual Studio IDE, click on the WebGrid instance and open Property Window.

The sample used classic paging mode, so our first step is to change the paging mode to VirtualLoad since the group row paging is an integral part of VirtualLoad paging. To set the paging mode, expand LayoutSettings and set the PagingMode property to VirtualLoad. See below.


The next step is to enable the group row paging, customize the group row paging size, and optionally enable the preload group totals as well as other client binding related settings.

Still in the Visual Studio’s Property Window, expand the ClientBindingSettings property. You’ll find most of the client-binding related settings centralized in this property group. Enable the group row paging by simply setting its property to true and configure other settings to follow the screenshot below.


We’re done with the WebGrid-level configuration.

Configuring WebGrid LINQ Provider

After configuring the WebGrid to use proper client binding settings and group row paging, the next step is to configure the new LINQ provider in your application.

To use WebGrid LINQ provider in your application, add the ISNet.Data.Linq assembly from WebGrid installation folder to your application’s Bin folder. If you’re installing using default setting, the new assembly should be located in C:\Program Files\Intersoft Solutions\WebUI Studio for ASP.NET\WebGrid.NET 7.0\Bin.

Note that this is a new assembly shipped in the service pack installer. Download the latest service pack installer here, or obtain the assembly in the provided samples in the last section.

Handling Data Operations with LINQ-to-SQL Classes

Since we’re using client binding mode with WebService datasource, we need to specify the ServiceUrl property to the path of the web service that handles data operations requested by WebGrid. The sample used in the walkthrough is using WebService.asmx.

In this walkthrough, we’re going to define the service methods used to perform data selection and batch update. The select method is defined in SelectMethod, while the batch update method is defined in BatchUpdateMethod. The property settings can be seen in the screenshot below.


After wiring the service methods, the final step is to write each web method in the web service that corresponds to the specified service methods above.

Open the code-behind file of the web service to your Visual Studio IDE by right clicking on App_Code\WebService.asmx.cs then choose View Code.

Write the code for the data selection such as below.

public object GetPagedBugs(DataSourceSelectArguments selectArguments)
    BugTrackerModelDataContext context = new BugTrackerModelDataContext();
    context.DeferredLoadingEnabled = false;

    WebGridDataProvider provider = new WebGridDataProvider(context.Bugs.AsQueryable());
    object data = provider.Select(selectArguments);

    if (data != null)
         return data;

    throw new InvalidOperationException("Unsupported operation type!");

So simple, isn’t it?

As I’ve mentioned in my previous post, the Select method of the WebGrid’s LINQ provider automatically handles all data operations – from data paging, grouping, filtering, aggregate computation, group header selection, and group row paging.

I’ve also mentioned that the LINQ provider supports data transaction operations too – such as Insert, Update, Delete and BatchUpdate. The following code shows how to perform batch update using the new data provider.

public TransactionResult UpdateBugs(List changes)
    BugTrackerModelDataContext context = new BugTrackerModelDataContext();
    WebGridDataProvider provider = new WebGridDataProvider(context.Bugs.AsQueryable());

    return provider.BatchUpdate(changes);

It’s as simple as that – thanks to the bare-metal architecture built on the client binding, batch update, virtual load paging and the LINQ data provider to produce this level of component integration.

Now save your changes and view your page in the browser. Try to group the column by Operating System and you should see something like the following.

WebGrid with GroupRowPaging

So far, you have learnt how to enable group row paging, customize the page size, activate group total preloading, and use the new LINQ data provider to simplify client-binding data operations. Your next step is to test the new features and implement them in your web apps.

Download Samples

In case you haven’t got the chance to download the full service pack installer, you can quickly download and install the latest bits right from your Update Manager. However, it’s highly recommended that you to go through downloading the full installer to enjoy numerous new and enhanced samples that we included in the release.

You can find the new samples that I used in the walkthrough here. To try it, simply copy the entire folder into the root project of WebGrid C# Samples. I’ve excluded the references to WebGrid and other framework assemblies to reduce the download size, although I decided to include the ISNet.Data.Linq assembly for your convenience.

Enjoy and happy developing!

All the best,


Introducing Virtual Group Paging In WebGrid 7

We’ve been heavily focusing on performance and scalability aspects in the last two versions of WebGrid. As you may have already aware, WebGrid Enterprise 7 introduces numerous noteworthy new features such as client binding, JSON serialization, virtual rendering, efficient batch update and more – which elegantly address performance issues commonly found in enterprise applications.

The next release of WebGrid will still be strongly focused in various areas of performance to deliver even better data visualization component that is not only rich, but also speedy and highly scalable. Many of the new enhancements in the next release are designed to support combination of multiple advanced features, such as using client binding together with virtual load paging, grouping and data aggregates.

This post details some of the key enhancements to give you an insight for the usage in your applications.

Preload Group Totals

WebGrid 7 introduces a new client binding model where the data rendering is performed in the client-side instead of server-side. While there are many benefits with client binding, it falls short when it comes to extensive data aggregation such as calculating group totals on several hundreds or thousands of records.

The upcoming release will include a new capability to preload the group totals during server-side data fetching process, and hence eliminating the needs to compute heavy aggregation in the client-side, while maintaining the data footprint in a good balance.

This new feature also works along side with virtual load paging, which makes more sense on the “preloading” factor. Your users would definitely like the ability to see all group totals without have to expand each group to retrieve the rows. See the following screenshot for details.

Group totals are preloaded in advanced, allowing users to analyze data without have to expand the group row.

When using ServerDataSource type, the group totals will be automatically computed without additional user codes. Simply enable the PreloadGroupTotals property in ClientBindingSettings should do the job.

This new feature is also consistently supported by other client binding data source such as Web Service and WCF Service. Read the explanation in the latter section.

Group Row Paging

One of the advanced features that truly sets WebGrid apart from other Grids is its VirtualLoad™ paging capability. When enabled, virtual load retrieves only the first subset of data and then smartly loads the rest records as users scroll downward. The virtual load also uniquely supports grouping condition by displaying only the group headers and group totals in the first load. When users expanded a group row, WebGrid loads the child rows on demand via AJAX callback and then seamlessly inject it into the group row element. This gives users the feel of working with desktop apps.

Everything is good until your users accidentally grouped a data resulting with large amount of rows per group. It becomes worse when the Grid is working in client-binding since the rendering operation is done in the client-side. Imagine looping through thousands of records to perform string-extensive operations, the browser itself naturally refuse to complete the operation. And hence, you’ll get a prompt that ask you whether you want to stop or continue the script. Although you can choose to continue the script, it will still take several seconds to complete. This is certainly not a desirable result for most of today’s users who expecting applications with rich experiences.

Toward that end, we’re researching a solution that will not only address the performance issue permanently, but also works consistently across existing features and certainly with an intuitive user experience. As the result, group row paging is born.

With the new group row paging capability, you no longer have to worry how much data your Grid is presenting, whether they are grouped or not, whether they are filtered or not, WebGrid will display your data in the same timely fashion – consistently. To understand how group row paging works, please see the following image which also shows the new group row paging user interface.

The new group row paging interface.

The above sample is using GroupRowPageSize=10 configuration, which means only 10 records should be fetched in a time. As shown above, the new group row status enables users to easily understand the current state of the group row. It’s especially useful when the GroupRowPageSize is set to a larger value such as 100 (50 is the default) as users can see the current status without have to scroll back and forth to the group header. The new status bar also serves as command bar and allows room for improvements in the future, such as adding more buttons related to the group’s context.

Compared to the original sample without group row paging, the same group with 1,000+ rows now loads in a fraction of second, and that’s about 100x faster. The group row paging will consistently support multiple groups and other grouping-related features too.

It’s also noteworthy to mention that other useful features such as data editing, batch update, and row selection persistence will continue to work flawlessly along with group row paging.

Virtual Load Support For Web & WCF Service

Still around client binding and virtual load, we’ve now added virtual grouping (means virtual load + grouping) support for WebService and WCF Service as well. In the current release, the grouping process will invoke a Select command against the underlying WebService and retrieve all groups and rows from the database, which ultimately transmit 1-2MB size of data to the client. In most cases, you’ll get a server-side exception when the data exceeded 2MB because .NET’s JSON Serialization limits it to only 2MB by default.

In the next release, WebGrid will automatically send a new SelectGroup option in the select arguments when it attempts to perform grouping, or perform data selection in grouping conditions. This will allow developers to handle the group retrievals based on the select operation mode in the server-side and returns only the groups information to the client.

Our experiment shows that virtual grouping using Web Service or WCF Service is at least 4x faster and much more efficient than using ServerDataSource, especially when the processed data is huge. That is possible because developers have granular control over the data selection process, and in this case selecting only the groups from the backend directly without have to deal with the data rows.

The following code snippet demonstrates how it works.

if (selectArg.OperationType == SelectOperation.SelectGroup)
     var groupResults = dataSource.GroupByMany(selectArg.GroupByExpression);     
     return ProcessGroupRows(groupResults, selectArg);

Notice that the select operation type and group expression will be provided in the select arguments to allow developers to handle their data selection. The above sample is using LINQ to SQL to process the grouping request, which returns only the group rows required by WebGrid.

The two-minutes video below shows the improved performance and the user experiences when virtual load, group row paging, client binding and batch update are enabled together.

Furthermore, the new PreloadGroupTotals and GroupRowPaging feature that we discussed earlier can also be used with WebService/WCF Service data source type. In the client-side, WebGrid will perform the data rendering in consistent fashion, such as the new group status interface and the group loading behaviors.

WebGrid LINQ Data Provider

In addition to the performance and UX improvements, we’ll also ship LINQ to SQL data provider for WebGrid in the next service pack release. The new data provider greatly simplifies the codes to perform data operations using LINQ to SQL, specifically when paired together with WebGrid’s client binding.

The WebGrid LINQ data provider minimizes complexity and slashes dozen line of codes into one line. See the following comparison.

The following is the original codes that we shipped in our WebGrid 7 samples.

Original, lenghy codes required for data operation.

And here’s the new approach using WebGrid LINQ Data Provider.

Simplified code using WebGrid LINQ provider.

One code rules it all – that’s what I really like about this new data provider. The generic-based class architecture enables you to easily instantiate the provider on any of your data model by simply passing the data type – making development more efficient and fun!

In this first version, the WebGrid LINQ provider will automatically handle the following select operations during client binding:

  • Data Selection
  • Sorting
  • Filtering
  • Grouping
  • Paging and Total Rows Count
  • Group Selection
  • Group Row Paging
  • And yes, group totals too.

In addition to data selection, the provider also includes full-featured transaction operations, such as:

  • Insert
  • Update
  • Delete
  • Batch Update

And now comes the best part, the LINQ data provider is free for all WebGrid licensees. To start using it in your application, simply add reference to the new assembly named “ISNet.Data.Linq” which can be found in WebGrid’s installation folder. When the enhancements are rolled out in the next service pack, I’ll post more blogs to cover how to use them in more details.


This blog post gives you an insight and early look on some key enhancements that we’re currently working on for the next WebGrid release. Customers who wish to test drive these new enhancements, please obtain the nightly build (and yes, we have prepared some new samples too!) by directing your email to our Support Team.

We hope customers to participate in the beta testing and give feedback, so we can review and take account your feedback before wrapping up the final features. You can send your feedback to Feedback Team for private discussion (if your feedback includes confidential information related to your apps etc), or to Community Forum for open, shared discussion.

All the best,