Tag Archives: Client Binding

Coming in 2011 R1: WebCombo 5 and Enhanced WebGrid for ASP.NET

The upcoming WebUI Studio 2011 volume release will include a host of new controls across all .NET development platforms, including Silverlight, WPF, and ASP.NET. In the past few months, I’ve been actively blogging about the upcoming new controls for the Silverlight and WPF development. In this post, I’ll unveil the new controls and key enhancements for ASP.NET platform that we will deliver in the 2011 volume release.

WebCombo 5 Features Client-side Binding and Web Services Support

The 2011 volume release will include a new version of our flagship ASP.NET WebCombo control. WebCombo 5 is now built upon the rock-solid Client Data Object Framework (CDOF), the same framework that powers WebGrid Enterprise 7 to provide rich client binding functionality. As the results, you can now use WebCombo to bind data to web services such as web services, WCF services, ADO data services, Azure or other cloud-based data services.

Client-side binding has a number of benefits such as producing smaller data output size between callbacks which greatly improve application’s performance in overall. Our test with various binding configuration show impressive results for client binding mode. See the following comparison chart.

Data size chart comparison

Notice that the WebCombo with any client-binding mode will reduce the data output size by 40 – 50%.

Another great feature that is made possible with the client-binding in WebCombo 5 is the pure client data source support. This means that you can create your own data source and bind it in the client-side, in the similar fashion as in server-side.

Interestingly, the client data source also enables you to retrieve data from RESTful services and bind the results to the WebCombo directly in the client-side. And the beauty of the client-binding framework is that all WebCombo features continue to work as expected, including multiple columns, auto-complete entry mode, link settings, multiple selection, and more.

That said, we’ve created several interesting new examples that demonstrate the power of the client-side data source. One of the examples is to retrieve photos from the Flickr through jQuery, and bind the results to the WebCombo in the client-side. See the screenshot below.

Binding WebCombo to Flickr Service

Full WCF Service Support in WebGrid Enterprise 7

Due to high demands, WebUI Studio 2011 will also ship with an enhanced WebGrid control for ASP.NET which includes full support for WCF data service. The WebGrid LINQ data provider has been enhanced as well to fully support data query and contract serialization in the WCF service.

You can now elegantly retrieve the select arguments and other passed parameters in the WCF service, which was one of the unsupported features in the existing release. With the updated WebGrid LINQ data provider, querying data requires only a few line of code, see the code example below.

[OperationContract]
[ServiceKnownType(typeof(List))]
public object GetCustomers(WcfDataSourceSelectArguments selectArguments)
{
    NorthwindDataContext context = new NorthwindDataContext();
    context.DeferredLoadingEnabled = false;
    context.ObjectTrackingEnabled = false;

    WebGridDataProvider provider = 
                   new WebGridDataProvider(context.Customers);

    return provider.Select(selectArguments);
}

The client-binding, data services, LINQ providers and cloud support are significant milestones in our ASP.NET development roadmap. They are the precursor to the modern, RESTful web development that is server-pages agnostic.

I hope this post gives you some ideas on the new capabilities that you can add to your web applications using the client-binding and WCF support in the new WebCombo and WebGrid. As usual, comments and feedback are open.

Best,

Jimmy

Advertisements

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.

Configure_VirtualLoad

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.

Configure_ClientBinding

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.

Configure_ServiceMethods

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.

[WebMethod]
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.

[WebMethod]
[GenerateScriptType(typeof(Bug))]
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,

Jimmy.

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.

Summary

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,
Jimmy.