The Blog of Milos

Web.UI 2008.2 Grid News: Grouping

Milos — Tue, 23 Sep 2008 18:34:00 GMT

Now that Web.UI 2008.2 is officially out the door, I can take some time to sit back and reflect on what's been done. There are some great new controls, as usual, and major enhancements to our Grid control.

I'm particularly excited about that last part, as I've felt for a long time that some of the limitations with its grouping functionality needed to be addressed. With this release, we took the time to really re-think this aspect of the control, and instead of merely patching on additional features, to remake it in a powerful and elegant way and still keep it backward compatible. I believe we've managed to do that.

So, without further ado, here's what's new with Grid grouping:

Multiple Grouping

One of the Grid's major deficiencies for some time has been its inability to group by more than one column at a time. This had to do with various factors having to do mostly with the way we were rendering groups on the client. We have now surmounted those obstacles and groupings can be done on as many columns at a time as the user deems reasonable.

This ability extends across all running modes, usage scenarios and grouping modes.

Wait... Grouping modes?

Grouping Modes

When re-thinking the way grouping should work in Grid, we realized that there are at least three different ways in which paging through a grouped record set could work:

ConstantRecords; in this mode, the number of actual data records, regardless of how many groups they are distributed across, remains constant across pages. This mode is very simple to handle programmatically, since data-access code doesn't actually need to know anything about groupings. It simply retrieves the one page of records, which are then organized in appropriate groupings before being rendered on the client.

See demo here: ConstantRecords Grouping Mode

Thanks to its simplicity, this grouping mode is supported in all running modes, including WebService.

ConstantGroups; this mode replicates the default grouping behaviour that Grid exhibited up to this point. Paging a Grid grouped in this mode means that the same number of top-level groups is present on every page. All the contents of those groups (sub-groups and records) are pre-loaded and no additional data access is required to expand and render that content.

See demo here: ConstantGroups Grouping Mode

ConstantRows; the two modes described above have one common downside: as groups are expanded on the client, the number of rendered rows increases, and can stretch the height of the Grid control. With ConstantRows, the total number of rendered rows (records + group headings) is kept at the constant number dictated by GroupingPageSize.

See demo here: ConstantRows Grouping Mode

This running mode, when used in Server or Callback mode, requires some new server-side events (NeedGroups and NeedGroupData) to be handled in order to facilitate the efficient retrieval of only the necessary groups and records.

Which brings us to our next topic...

Grouping + Manual Paging

Up until this point, there was no good way to use manual paging (manual retrieval of just the required records from the database for each page) in conjunction with grouping with ComponentArt Grid. With the ConstantRecords and ConstantRows grouping modes, that is no longer a problem. Grouping can now be done while maintaining the efficiency of manual data retrieval.

Grouping + Scrolling

The ConstantRows grouping mode provides an additional important benefit. To support grouping in conjunction with the Grid scroller, maintaining a constant number of rendered rows was crucial. A Grid which changes its height as it is scrolled completely ruins the visual feel of a scrolling interface. With ConstantRows, grouping can finally be used with the scroller.

See a demo here: Scrolling a Grouped Grid in Callback Mode
And here: Scrolling a Grouped Grid in Client Mode

Grouping + Web Services

Grid's WebService running mode, while offering the best possible performance and elegance of design, does have limitations due its inability to perform complex server-side logic as data is loaded. This makes it difficult to support the loading of groups on the server (web service), but once again, the grouping modes greatly improve the situation.

The ConstantRecords grouping mode is easily supported in WebService running mode, since it only relies on the regular paging of records. Through this mode, grouping is now supported with web services. In the future, we will be expanding this functionality to support as much of the other two grouping modes as we can, but we feel that this is already a decent start.

See a demo here: WebService Running Mode

Conclusion

We hope you find Grid's new grouping functionality useful. We will continue to improve it and, as always, take your views and needs into account. Do let us know what you think.

Enhanced grouping isn't the only thing that's new in Grid 2008.2, but it's certainly the most significant. Nevertheless, I will be writing about the other Grid enhancements in a follow-up post. Stay tuned.

Share this post: email it! | bookmark it! | digg it! | reddit!

Grid Configuration via Web Service

Milos — Fri, 13 Jun 2008 13:35:00 GMT

Since the introduction of the WebService running mode in ComponentArt Grid, and related functionality (like the client-side load method), we have seen this approach rapidly gain popularity and, naturally, produce demands for more features and more versatility.

Versatility is key when it comes to UI controls, so we have been spending some time improving WebService mode in this respect. As of Web.UI 2008.2 SP2 (build 2008.2.1180) Grid has a number of new features.

WebServiceConfigMethod

In addition to being able to define ASP.NET AJAX web service methods for data selection, insertion, deletion, etc, it is now also possible to perform Grid configuration in a web service.

Rather than defining top-level properties, GridLevels and their constituent GridColumns and all the accompanying styles on the ASPX page where the Grid instance is placed, all of these can now be loaded on the fly by defining the WebServiceConfigMethod server-side property and calling the client-side webServiceConfig method.

GridWebServiceConfigResponse

The web service method performing Grid configuration is expected to return an object of the type GridWebServiceConfigResponse. Such an object contains top-level property settings (contained in the Properties member), and GridLevel definitions (contained in the Levels property) which, in turn, can contain GridColumns.

Configuration can be done at any time on the client, without going back to the server from which the ASPX file originated. The configuration request passes in an optional custom parameter, so that configuration can be context-dependent.

GridWebServiceSelectRequest.Columns

To enable such potential on-the-fly changes to the Grid’s layout and definition, GridWebServiceSelectRequest now contains a Columns property. With every web service data request, Grid now sends along the collection of columns (data fields) that it expects on the client. This allows the web service selection logic to account for on-the-fly changes in the Grid’s client-side configuration, and always provide the required data.

And More

In addition to the above, a number of other enhancements to web service functionality have been made which should simplify its use in many scenarios and enable altogether new ones.

For example, GridWebServiceSelectResponse.Items can now contain simple arrays of objects corresponding to the rows of data requested by the Grid. Simple proxy classes no longer need to be defined, as long as the order of data in the arrays matches the fields specified in GridWebServiceSelectRequest.Columns.

The select response can now also contain hierarchical data, with rows containing more rows defined on the second (or third, etc) GridLevel. To keep on topic, I will write more on this particular functionality at a later date.

Cheers, and thanks for stopping by!

Share this post: email it! | bookmark it! | digg it! | reddit!

AJAX With ASP.NET MVC and ComponentArt CallBack

Milos — Thu, 01 May 2008 18:08:00 GMT

Web.UI vNext (preview build included in attached project packages) will include, among other things, a new feature of the CallBack control which will allow it to become extremely useful for integrating AJAX functionality in web applications build on Microsoft’s new ASP.NET MVC framework.

About Microsoft ASP.NET MVC

A few months ago, Microsoft announced a new, alternative framework for ASP.NET applications built around the model-view-controller architecture pattern. Scott Guthrie blogged about it and described in detail how this framework operates. Though still in a preview stage, ASP.NET MVC has already generated a lot of buzz and interest, and promises to be an important factor for some types of web apps. However, ASP.NET MVC has no AJAX support out of the box.

About ComponentArt CallBack

ComponentArt CallBack is a relatively simple ASP.NET control which contains HTML content and allows it to be updated asynchronously via AJAX calls back to the server. In a typical web form, the request is sent back to the page of origin and is handled by the control itself, which raises an event, allowing the developer to compose the content to be sent to the client.

A new feature introduced to CallBack for the next version of Web.UI is the client-side loadUrl method. This method allows the control to asynchronously call up any URL and display the content returned within its element on the page. This feature is useful for all sorts of situations, including rapid integration of partial AJAX updates in web applications built on Microsoft’s ASP.NET MVC framework.

ASP.NET MVC and ComponentArt CallBack

ASP.NET MVC request routing operates according to conventions for HTTP GET requests. Requests for pages are of the form /Controller/Action/Id, and the logic of the application is built to follow this flow: the appropriate Controller accepts the request, and handles the requested action by performing the appropriate business logic (in conjunction with the Model) and passing resulting data to the appropriate View which is then rendered to the client.

This architecture is a complete departure from that of ASP.NET web forms, which is based on postbacks and persistence of control state. The traditional use of CallBack (by raising server-side events to handle a callback request) is no longer applicable. However, with the addition of the loadUrl method, CallBack fits perfectly into the ASP.NET MVC architecture and provides the easiest and most integrated way of performing partial AJAX updates in an ASP.NET MVC application.

How it Works

When designing functionality that is to be useful for ASP.NET MVC apps, we found that less is more. Since the MVC model forces us to drop most of the complexities of the ASP.NET web form life cycle, control state and server-side events, we are left with just the basics of HTTP. In this case, that is all we need, and it is also the best way to seamlessly integrate into the MVC way of doing things.

CallBack's loadUrl method causes CallBack’s content to be loaded from the given URL, which, of course, can follow MVC conventions. We are therefore able to have a CallBack control on an MVC View Page (say, CallBack1), get it rendered to the client, and from that point, only interact with it on the client side, to perform actions and load new content, with typical calls like these:

CallBack1.loadUrl('/Search/Beverages/23');
CallBack1.loadUrl('/Products/List/Beverages');

On the server, layout is organized as a standard ASPX View, with distinct parts encapsulated in ASCX views.

After the initial ASPX view is loaded, those parts of it which are encapsulated in ASCX views (and placed inside instances of ComponentArt CallBack) can be updated asynchronously.

Organizing content areas in ASCX views is the key component of our MVC AJAX solution.

The loadUrl method also takes an optional second parameter, POST data. If data needs to be sent that is not part of the URL (including the optional query string), it can be combined into a POST data string on the client (in the form "name1=value1&name2=value2") and passed to loadUrl. It will be available in the MVC controller as part of the Request.

Examples

To illustrate these ideas, I include two examples below. With these web application projects, I have tried to demonstrate how Web.UI controls can be used in the context of MVC, including how partial AJAX updates can be performed with the CallBack control while maintaining the full MVC pattern. There are two separate applications:

MvcChartGallery

This ASP.NET MVC web application is an adaptation of a typical application dealing with hierarchical data, featuring ComponentArt Web.UI controls. The architecture of the web application uses simple one-time rendering of the controls, taking them out of the paradigm of web forms. Interaction with the controls causes full-page refreshes with appropriate MVC routing. Context data is passed in URL query parameters.

MvcAjaxChartGallery

This ASP.NET MVC web application is a reworking of the above example which encapsulates autonomous areas of the UI into MVC User Control Views, which are in turn placed inside instances of ComponentArt CallBack, allowing them to be updated independently and asynchronously (see diagram 2). Most importantly, these partial updates are HTTP requests MVC User Control Views and are fully routed through MVC. They can be treated in the same way as any other MVC request, and application logic does not need to do anything special to allow for this asynchronous operation, nor indeed to be aware of it at all.

Conclusion

Though still in an early preview stage, ASP.NET MVC has attracted a lot of interest and shows a lot of promise to grow into an important web technology. However, as of yet, ASP.NET MVC has no built-in AJAX support. Despite its divorce from web forms, applications built on ASP.NET MVC can still utilize rich ComponentArt Web.UI controls, and use the CallBack control, in particular, to quickly and easily add AJAX functionality in a way that seamlessly fits into the MVC pattern.

Share this post: email it! | bookmark it! | digg it! | reddit!

TreeView and Web Services

Milos — Wed, 23 Apr 2008 17:49:00 GMT

In my previous post, I talked about the web service functionality that's common to all ComponentArt navigation controls. I focused on common features that are present in many different controls, especially in this case, but this approach was unfair to one control. With its ability to load chunks of data on demand, TreeView is the odd man out, supporting everything that other navigation controls do, but adding its own unique twist.

Like the other navigation controls, TreeView has control-level WebService and WebServiceMethod properties. These determine which ASP.NET AJAX registered web service will be called, and which method of that service, when nodes are retrieved. For the initial data load, the behaviour is identical to Menu, TabStrip or NavBar. What TreeView can do that others can not is to only load some nodes initially, letting user actions determine what else gets loaded and when. Essentially, TreeView is able to operate in load-on-demand mode with web services.

To return load-on-demand nodes (parent nodes with no child nodes pre-loaded), simply set their UseWebService property to true. This will notify TreeView to consider these nodes to be parent nodes, and to call the web service again when they are expanded, to load their child nodes. When that happens, the same WebServiceMethod will be called, but with a twist: the TreeViewWebServiceRequest object that is passed in will have its Node property set to the node that requires data. Based on the Text, Value or ID of this node, appropriate new nodes can be created and returned, as they would normally, from the web service method. Note that these child nodes can also have their UseWebService property set to true.

After a web service call completes, the client-side event also exposes the node for which the call was made, in addition to the customData property common to all navigation controls. Here's an overview of the client-side TreeViewNodeWebServiceCompleteEventArgs class:

function TreeView1_webServiceComplete(sender, eventArgs)
{
  var node = eventArgs.get_node();
  
  if(node)
  {
    alert('Completed web service call for node ' + node.get_text());
  }
  else
  {
    alert('Completed web service call for top level data.');
  }
  
  var customData = eventArgs.get_customData();
  
  if(customData)
  {
    alert('Web service call returned custom data: ' + customData);
  }
}

You can see an example of this functionality online with the TreeView Web Service Load-on-demand sample. Please note that this functionality is fully available only as of Web.UI 2008.1 SP1, released on April 23rd 2008.

Summary

To recap, since TreeView can load node-specific partial data through web services (unlike other navigation controls, which can only load all the items at once), its related API is a superset of, say, that of Menu. TreeViewWebServiceRequest includes the Node property (null for initial, top-level loading), TreeViewNode has the UseWebService boolean, and the client-side TreeViewWebServiceCompleteEventArgs class includes a node property. These extensions enable efficient load-on-demand functionality built entirely on ASP.NET AJAX web services.

Share this post: email it! | bookmark it! | digg it! | reddit!

Web.UI Navigation Controls and Web Services

Milos — Tue, 01 Apr 2008 17:45:00 GMT

It's been some time now since we first started introducing client-side integration with ASP.NET AJAX web services into our controls. The first foray was the ability of Grid to bind directly to JavaScript object arrays, allowing it to directly load JSON data returned from a web service, and continue running in client mode (see demo). The interest that this generated prompted the next big wave: Grid’s WebService running mode (see demo) and web service functionality in all the major navigation controls: TreeView, Menu, TabStrip, NavBar and ToolBar (see demo).

In the latest iteration of Web.UI (2008.1) we standardized client-side events relating to web service calls across this group of controls, and added the ability to pass custom data to and from the web services. Each *WebServiceRequest and *WebServiceResponse class now has a CustomParameter property.

In this blog post, I want to illustrate how this custom data can be bounced around using standard client-side and server-side properties and client events.

Take as an example a Menu control, pointed at an ASP.NET Web Service:

<ComponentArt:Menu runat="server" ID="Menu1"
  WebService="MyService"
  WebServiceMethod="GetItems"
  WebServiceCustomParameter="Blue"
  ... />

In the above example, we are telling Menu to call the WebMethod GetItems of the service MyService, and to set the initial value of its WebServiceCustomParameter to "Blue". When the Menu loads on the client, it will do just that. Let’s see how we can access the custom parameter in the web service:

[System.Web.Script.Services.ScriptService]
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class MyService : System.Web.Services.WebService
{
  [WebMethod]
  public MenuWebServiceResponse GetItems(MenuWebServiceRequest request)
  {
    // Create a response object.
    MenuWebServiceResponse response = new MenuWebServiceResponse();

    // For this example, we will only return one item,
    // with the Text matching the custom parameter given to us.
    MenuItem newItem = new MenuItem(); 
    newItem.Text = request.CustomParameter;
    response.AddItem(newItem);

    // We will also return some custom data from the server.
    // Let’s make it the current time.
    response.CustomParameter = DateTime.Now.ToString();

    // Send the data back.
    return response;
  }
}

When this Menu loads on the client, it will load up the web service data, which will result in a single menu item entitled "Blue". We can always re-load data from the client by calling Menu’s client-side loadFromWebService method. We can also change the WebServiceCustomParameter on the client before doing so. For example, the following JavaScript would result in the Menu reloading its data and ending up with a single item entitled "Red":

Menu1.set_webServiceCustomParameter('Red');
Menu1.loadFromWebService();

This mechanism should enable unlimited reloading of data for any navigation control based on custom data passed from the client. One last thing remains to be answered: how do we access that custom data (the server time) we sent back to the client from the web service? This is where client events come in. If we want access to this custom data, we’ll have to hook the WebServiceComplete client event:

<ComponentArt:Menu runat="server" ID="Menu1" ... >
  <ClientEvents>
    <WebServiceComplete EventHandler="Menu1_WebServiceComplete" />
  </ClientEvents>
</ComponentArt:Menu>

In the event handler, we can access the custom data through the event arguments parameter:

function Menu1_WebServiceComplete(sender, eventArgs)
{
  alert('Loaded items from web service, along with this custom data: ' +
    eventArgs.get_customData());
}

I hope that explains this exciting new functionality and that you find it as neat and useful as we do. Do let us know what you think and how we can build on this in the future.

Share this post: email it! | bookmark it! | digg it! | reddit!

Introducing ComponentArt Upload

Milos — Fri, 28 Mar 2008 12:21:00 GMT

ComponentArt Web.UI 2008.1 includes one new addition to the library of controls: Upload. ComponentArt Upload is a file upload control with all the high-end AJAX and client-centric functionality one should expect from a Web.UI control.

The control comes with a custom server-side HTTP module for optimally processing the file upload, and an HTTP handler which provides upload progress information and otherwise enables communication between the module and the control on the client.

On the client, progress feedback is provided using client templates, in which all the metrics related to the upload (percentage, elapsed time, file sizes, speed, filenames, etc.) can be accessed and displayed in any layout the developer defines. File input fields (there can be more than one) are also formatted and styled using client templates, again with unlimited visual potential.

To configure an Upload control, the HTTP module and the handler must be added to the application’s web.config file:

<httpModules>
 <add type="ComponentArt.Web.UI.UploadModule, ComponentArt.Web.UI"
  name="ComponentArtUploadModule"/>
</httpModules>


<httpHandlers>
 <add verb="*"
  type="ComponentArt.Web.UI.UploadProgressHandler, ComponentArt.Web.UI"
  path="ComponentArtUploadProgress.axd" />
</httpHandlers>

Once this back-end infrastructure is in place, an Upload control can be placed on a page of the application:

<ComponentArt:Upload runat=”server” ID=”Upload1” TempFileFolder=”c:\temp\uploads” ... />

The Upload control writes files to disk as they come in, to prevent the waste of memory on the server, so TempFileFolder must be set on the control, to the absolute path of a folder where uploads are to be stored as they happen.

When an upload completes, the file(s) can be handled via the control’s Uploaded event, or by setting the DestinationFolder property, which will cause successful uploads to automatically be moved to the specified folder. In the latter case, automatic validation can also be performed before moving, using the AllowedFileExtensions and AllowedMimeTypes properties.

Styling of the control is done almost exclusively with client templates. The input area, as well as the progress feedback, can both be client-templated. In the latter case, extensive information on upload progress is available to be used in the template.

The progress client template (specified using the ProgressClientTemplateId property) is rendered in a popup over the upload control by default. If the ProgressDomElementId property is set, the client template will instead be rendered into the specified DOM element, allowing external controls to be used for progress feedback, such as the ComponentArt Dialog control.

The value of the boolean AutoPostBack property determines whether a postback will occur when the upload completes. If false, a callback is performed instead, and Upload's server-side event handler (or DestinationFolder logic) is still executed right away, without the page visibly reloading.

We hope you find this new control useful. We're pretty excited about what it brings to the field and the bar it sets for rich client-side styling and formatting. Try it out and let us know what you think.

You can start by checking out the Upload samples online.

Share this post: email it! | bookmark it! | digg it! | reddit!

Toronto Code Camp 2008

Milos — Mon, 03 Mar 2008 19:07:00 GMT

Two days ago, on Saturday, I attended Toronto Code Camp 2008, the third such event organized in our fair city. It was my first time at a Code Camp and I had a good time and learned a lot. In addition to attending some very interesting presentations and chatting with people from the ASP.NET community, I got to speak as well! My talk was about how ASP.NET AJAX exposes web services on the client, and how that can be connected with "client-centric" controls, such as those in Web.UI. After some introductory examples of accessing web services from client-side code, I demonstrated how ComponentArt TreeView and Grid can load data directly from web services using the ASP.NET AJAX.

Those interested can download the (simple, introductory) code samples here.

P.S. After the talk, Joel Tulloch pointed out to me that it isn’t necessary to mirror the server-side classes on the client by hand. We can use the GenerateScriptType attribute for this, as he describes on his blog. Very neat stuff.

Share this post: email it! | bookmark it! | digg it! | reddit!

New Grid Feature: CallbackParameter

Milos — Wed, 19 Dec 2007 23:26:00 GMT

A common scenario that our users encounter with the Grid is the need to populate it with different data depending on client-side context – for instance, a dropdown option or a TreeView selection. Very often, this situation is solved by to setting Grid to Server or Client running mode and wrapping it in a CallBack control, and then using the CallBack to send custom parameters back to the server and to refresh the Grid.

This has worked well for many, but is not without its limitations, mostly having to do with CallBack’s inability to maintain state across callbacks. It also seems somehow wrong and wasteful to approach things this way and completely ignore Grid’s own ability to issue callbacks, and maintain its own state.

To remedy this slightly awkward situation, we’ve introduced and small (but hopefully important) new feature to Grid as part of Web.UI 2007.2 SP1: the CallbackParameter property. This property can be set on the server or the client, and is sent back with every callback issued by the Grid. A Grid in CallBack running mode exposes this value on the server in time for every server-side event, and the value will mirror that on the client. So, where before we may have done something like this:

CallBack1.callback(‘mailbox’);

we would now do away with the CallBack control altogether, and do this instead:

Grid1.set_callbackParameter(‘mailbox’);
Grid1.callback();

Conditional logic on the server can then do the right thing based on the value of Grid1.CallbackParameter. To further facilitate this parameter-based loading, we’ve added two more server-side Grid events: BeforeCallback and AfterCallback. These are raised before and after (respectively) all the other events raised during a Grid callback request.

Hope you find this useful! Let us know what you think.

Note: This feature is available as of Grid 2007.2 SP1, available Dec 17. 2007.

Share this post: email it! | bookmark it! | digg it! | reddit!

Web Service Data Loading with Navigation Controls

Milos — Tue, 18 Dec 2007 16:18:00 GMT

Previously, I have written about Grid’s new WebService running mode, which allows Grid to communicate with an ASP.NET AJAX web service directly from the client, and do all its data loading through it, including paging, sorting, filtering, etc. This powerful functionality is also available on ComponentArt navigation controls: TreeView, Menu, NavBar, TabStrip and ToolBar. All of these have the ability to load their data from an ASP.NET AJAX web service. TreeView, furthermore, has the ability to load data for each node on demand. Since this functionality is a superset of the simple ability to fetch all the data at once, I’ll outline the more complex case here.

- On the server, we use the WebService and WebServiceMethod properties to set the name of the registered web service to use, as well as the name of the method to invoke to retrieve node data.

- The service WebMethod refered to by the control’s WebServiceMethod property should be implemented with the following signature:

public TreeViewWebServiceResponse MethodName(TreeViewWebServiceRequest request)

The above example is for TreeView – for other controls, the appropriate types should be used, eg. TabStripWebServiceResponse and TabStripWebServiceRequest for TabStrip.

- The method’s return value (a *WebServiceResponse) should contain the nodes to be sent to the control.

At this point, the work of defining a web service data source for a navigation control is complete. With the above setup, the control will fetch its data from the specified web service by invoking the specified method.

With TreeView, we often wish to configure data loading using an on-demand mechanism. This means that a node’s children are loaded only when that node is expanded and no sooner. To achieve this, we only need one additional step:

- Instead of populating a TreeViewNode with its child nodes, set its UseWebService property to true to specify that the web service should be used to fetch its child nodes. When this is done, the same WebServiceMethod will be invoked as for the root nodes, but the TreeViewWebServiceRequest’s Node property will be set to the TreeViewNode which needs to be populated.

That’s all there is to it.

Note: All the navigation controls also have a WebServiceCustomParameter which can be set on the server or the client, and which is sent back as part of every *WebServiceRequest. This should allow for custom context-dependant data loading.

For a simple demo of this functionality, check out the Web Service Creation sample on our site. For a look at web service-driven TreeView load-on-demand, take a look at this TreeView sample. A useful real-world application using TreeView and Grid, build entirely on web services, can be seen in the Full Web Service Application sample.

Share this post: email it! | bookmark it! | digg it! | reddit!

New Grid Feature: WebService Running Mode

Milos — Wed, 14 Nov 2007 16:30:00 GMT

Version 2007.2 of ComponentArt Grid includes, among other goodies, an exciting new feature: WebService running mode. We think it should be very useful for a lot of people so, in this post, I want to introduce you to this feature and explain how it works.

What is it?

Those who have used Grid will be familiar with the notion of a “running mode”. Until this point, Grid could be used in three different modes: Server, Callback and Client. Setting the RunningMode property to one of these determines whether Grid performs its data-related actions (paging, sorting, filtering, etc) via postbacks, callbacks, or entirely on the client.

The most efficient way of interfacing with large data sets was always the callback mode, but it had one downside: callbacks were made to the same ASPX page which houses the control, so each callback incurred the overhead of the ASP.NET page life cycle and auxiliary init code.

The new WebService running mode allows Grid to perform data operations via calls to an ASP.NET AJAX web service. We feel that this system provides maximal efficiency and design elegance by allowing us to completely separate our data access code from the ASP.NET page which houses the layout.

How do I use it?

To use web service running mode, start by setting Grid’s RunningMode property to WebService.

Then, set the WebService property to the name of the ASP.NET AJAX web service to use. You will also need to set the names of that service’s WebMethods to use for fetching items, or updating and inserting them. For this, use the WebService*Method properties (eg. WebServiceSelectMethod).

The web service should be registered with the ScriptManager in the usual way, and the specified methods should have standard signatures:

GridWebServiceSelectResponse SelectMethod(GridWebServiceSelectRequest req)
bool UpdateMethod (GridWebServiceUpdateRequest req)
bool InsertMethod(GridWebServiceInsertRequest req)

Selection

Most of the usual interaction with a Grid will be done through the select method, whose logic will handle all paging, sorting and filtering. Whenever a new set of records is required on the client this method will be invoked with all the necessary information to fetch the appropriate records. The GridWebServiceSelectRequest will contain the required page index, page size, sort order and any conditional filters. The response should contain all the necessary records (objects with appropriately named properties), and information about the total number of records, for purposes of paging.

Here’s an example of a simple select method which handles paging and sorting:

    [WebMethod]
    public GridWebServiceSelectResponse GetRecords(GridWebServiceSelectRequest request)
    {
      DataSet oDS = FetchAllData(); // implemented elsewhere, returns all records
      DataView oView = oDS.Tables[0].DefaultView;

      if(request.SortField != "") oView.Sort = request.SortField + " " + request.SortOrder;

      List list = new List();

      int pageSize = request.PageSize;
      int startRec = request.CurrentPageIndex * pageSize;

      for (int i = startRec; i < Math.Min(startRec + pageSize, oView.Count); i++)
      {
        Message msg = new Message();

        msg.Subject = (string)oView[i]["Subject"];
        msg.LastPostDate = (DateTime)oView[i]["LastPostDate"];
        msg.TotalViews = (int)oView[i]["TotalViews"];
        msg.StartedBy = (string)oView[i]["StartedBy"];

        list.Add(msg);
      }

      GridWebServiceSelectResponse response = new GridWebServiceSelectResponse();

      response.Items = list;
      response.RecordCount = oView.Count;
    
      return response;
    }

Inserting and Updating

Updating records and inserting new ones is done in very much the same way as selection. However, since these actions only affect one record, the request is a lot simpler and basically contains only the data for the item in question. The relevant classes are GridWebServiceInsertRequest and GridWebServiceUpdateRequest.

We hope this mechanism will allow for totally UI-independent data handling that communicates with the client-side Grid in the most efficient possible way. Because Grid is able to redraw itself on the client, there is no need to ever go back to the original ASP.NET page after it has launched the Grid. Developing this approach should be the way forward in taking client-centric web apps to the next level.

Let us know what you think!

Share this post: email it! | bookmark it! | digg it! | reddit!

SpellCheck Client-side API

Milos — Wed, 07 Nov 2007 18:55:00 GMT

The SpellCheck control, like most others in Web.UI, includes a powerful client-side API. The philosophy behind SpellCheck’s design is that as little as possible should be baked right into the control when it comes to visual interface, and that custom user experiences should be made as easy as possible via a powerful and versatile client-side API.

Below are some examples.

To check some text and see how many errors there are, we can do the following:

var text = "This is some text with spleling misteaks in it."

function spellComplete(result)
{
  alert('SpellCheck complete: ' + Spell1.get_numErrors() + ' errors found.');
}

Spell1.Check(text, spellComplete);

Continuing from the above example, this is how we can go through the errors and see what they are:

for(var i = 0; i < Spell1.get_numErrors(); i++)
{
  alert('Error number ' + i + ' is: ' + Spell1.getError(i));
}

We can expand the loop above to show the user what some alternatives might be for each of those errors:

var currentError;

function suggestHandler(result)
{
   alert('You typed\'' + currentError + '\' but maybe you meant to type one of these: ' + result);
}

for(var i = 0; i < Spell1.get_numErrors(); i++)
{
  currentError = Spell1.getError(i);
  Spell1.getSuggestions(currentError, suggestHandler);
}

We can also use the client-side API to change errors in the text right where they appear. For instance, we could alter the above to simply replace every misspelled word with the first suggestion returned by SpellCheck:

var currentErrorIndex;

function suggestHandler(result)
{
   text = Spell1.Change(text, null, currentErrorIndex, result[0]);
}

for(var i = 0; i < Spell1.get_numErrors(); i++)
{
  currentErrorIndex = i;
  Spell1.getSuggestions(currentError, suggestHandler);
}

In the above example, we’ve been passing around the text variable, which we defined ourselves. When SpellCheck’s ControlToCheck property is set, null can be passed instead of text to any method that requires it – the control will get the relevant text itself, and interventions will be made right on the text in question, whether it’s in a form field or any other DOM element.

We hope you find this useful. Let us know what you think.

Share this post: email it! | bookmark it! | digg it! | reddit!

Introducing SpellCheck

Milos — Tue, 06 Nov 2007 14:36:00 GMT

Version 2007.2 of Web.UI brings with it two new controls: Editor and SpellCheck. In this post, I will provide a brief overview of SpellCheck, describing its abilities and the design philosophy behind it.

SpellCheck, as its name suggests, is an ASP.NET control used for facilitating spellchecking on a web page. SpellCheck can be used to check the spelling of any textual content on a page, whether in an input field, text area, or any other element. It uses AJAX techniques to communicate efficiently with its server-side logic, and exposes a rich and versatile client-side API for controlling the checking process.

Dialog-based Checking

The most common way that people interface with spelling checkers is via a pop-up dialog. The dialog guides the user through the checking process, going through the errors in order and bringing up suggestions for each. When the process is done, the dialog closes.

For an example of this UI, check out our dialog-based SpellCheck demo.

SpellCheck’s client-side API includes an array of methods and events which were designed to facilitate such interaction, while imposing absolutely no restrictions on the nature of the dialog or its layout or styling.

Methods like dialogBegin, dialogChange and dialogIgnoreAll were designed to be invoked by buttons commonly found on spellchecking dialogs. Generic methods like getSuggestions are also used to move the process along. In our own example, we use this API to interface with SpellCheck using our own Dialog control. However, the same can be accomplished using any control or mechanism which invokes the dialog-related public methods.

In-place Highlighting with Context Menus

When the target being checked is a DOM element other than a form-field, checking can be done using in-place highlighting. This means that SpellCheck will actually intervene in the markup being targeted and highlight the words that are spelled incorrectly. When the user clicks on such a word, a context menu is displayed, offering a list of suggested words to replace the mistake. Since the context menu (a ComponentArt Menu, naturally) is populated on the client as needed, it can be styled in any way in its server-side definition, and simply pointed to using SpellCheck’s ContextMenuId property.

This mechanism is often seen as more convenient than a dialog-based one, and requires no external code to put together. You can see an example of this UI in our context-based SpellCheck demo.

Client-side API

The above examples are only the most common ways the spell checking process is organized. Since SpellCheck exposes all the key components of the process via its client-side API, it should support any novel interface that is envisioned. With methods like check, getSuggestions, change, ignore and addToDictionary, there are very few limitations to the kind of experience that can be designed around them.

Up next: more on SpellCheck's client-side API. Stay tuned.

Share this post: email it! | bookmark it! | digg it! | reddit!

Optimizing Web.UI Client Script Deployment

Milos — Mon, 29 Oct 2007 21:36:00 GMT

As part of an overall effort to optimize HTTP-related performance of Web.UI, version 2007.2 includes a new mechanism for reducing the overhead of client script deployment. Since the script files themselves are of manageable size, and drastically benefit from compression in many cases, the biggest overhead comes from HTTP round-trips. Each Web.UI control typically depends on anywhere from one or two to several script files, so the number of separate requests can affect the load times in a web application.

The ComponentArt ScriptHandler, a new feature of Web.UI 2007.2 can be used to dramatically increase the efficiency of this aspect of Web.UI, pushing it to its theoretical limits.

With ScriptHandler, you have the ability to do choose between three different ways of sending ComponentArt client scripts to the client in your web application:

1. Status quo

By default, script rendering will work exactly the same way it has until now. Each control will output its own set of scripts or register them with the ASP.NET AJAX ScriptManager. In the latter case, the scripts will get compressed by default, but the overhead of multiple HTTP requests will remain.

2. Output the entire Web.UI client library in one request

The new script deployment mechanism allows you to combine all Web.UI client script libraries into one and send them to the client as one chunk. This minimizes the number of HTTP requests (to a single one), and maximizes the benefits of compression. As of version 2007.2, the combined size of all client scripts, compressed, is 327 KB. Due to browser caching, this means that the Web.UI scripts will get loaded all at once, and only the first time a user visits the site.

To enable this feature, simply add the following two entries to your web application’s web.config file:

in <httpHandlers>:

<add type="ComponentArt.Web.UI.ScriptHandler,ComponentArt.Web.UI" path="ComponentArtScript.axd" verb="*"/>

in <appSettings>:

<add key="ComponentArtScriptControls" value="All" />

3. Output combined scripts of select controls in one request

If the size of the one-time download in option 2 is a concern, it can be further optimized by excluding from the download those controls which are never used in your web application. For instance, if you only use Grid, TreeView and Menu in your application, you can change the appSetting to

<add key="ComponentArtScriptControls" value="Grid,TreeView,Menu" />

This will cause the Web.UI framework to combine all the scripts on which these three controls depend on into one chunk, and send it to the client compressed, and in a way which promotes indefinite client-side caching. For the above controls, the download size would be 90 KB.

Note again that this is an application-wide setting, so the list of controls should include any ComponentArt controls that are used anywhere in the application.

This feature is available for preview now, in the Beta 2 build of Web.UI 2007.2. We hope you find it useful, and that it helps you squeeze that extra bit of performance out of our control suite and your website.

Share this post: email it! | bookmark it! | digg it! | reddit!

New Grid Feature: Client-side Binding to Web Service

Milos — Wed, 02 May 2007 19:36:00 GMT

Now that we got 2007.1 out the door, we can finally take some time to reflect on what we’ve done, and talk to you guys and gals out there about what’s new and notable in the release. It certainly feels good to be writing in a natural language for a change.

Since one blog post would hardly suffice for discussing all the new controls and cool new features, for now I’ll focus on only one particular new feature that I think a lot of you will be excited about: client-side binding to JSON objects with Grid.

One of the great features of ASP.NET AJAX is its ability to expose web services and their WebMethods to client-side code quickly and easily. Return values from WebMethods are automatically serialized to JSON and returned as such on the client. Since ComponentArt controls are fully functional on the client, there is nothing stopping them from being able to load data returned from such web service calls right on the client. Being able to programmatically populate our controls on the client is nothing new, but now, for the first time, there is a way to bind a control to a JSON data set on the client with a single line of code. This is what Grid’s new client-side load method is for.

There is a sample in our new demo package which showcases this functionality (here) but I will explain the key points.

First of all, we need a web service, with a WebMethod which will return a data set. This particular example uses a simple service we wrote called MessageService, which has a method called GetRecords that returns a List of Message objects. This list is populated by querying a table of forum posts and instantiating a rudimentary Message object for each one. After the list is built in the GetRecords method, it is simply returned.

Next, we expose this web service to the client using the ASP.NET AJAX ScriptManager:

<asp:ScriptManager ID="ScriptManager1" runat="server">

 <Services>

  <asp:ServiceReference path="MessageService.asmx" />

 </Services>

</asp:ScriptManager>

At this point, we can call our GetRecords method with a single line of JS:

MessageService.GetRecords(OnSucceeded);

The parameter we pass in is the handle of a client-side method to call when the method returns its result:

function OnSucceeded(result)

{

  Grid1.load(result);

  Grid1.render();

}

The call to Grid’s load method with the returned JSON data set is all that is needed to bind the Grid with the new data on the client. The call to render then simply redraws the Grid.

I know, that’s pretty cool, right?

Note that in order for the Grid to know which properties of those JSON objects to load for the various columns, its column DataField definitions must match the property names of the objects, in this case the Message object.

Note also that such objects need not necessarily be loaded from a web service. Any array of client-side objects can be loaded using the load method.

Hopefully we’ll get a chance to implement similar functionality for some other controls fairly soon, like TreeView, ComboBox, Menu, and others.

Bye for now!

Share this post: email it! | bookmark it! | digg it! | reddit!

CallBack vs. UpdatePanel?

Milos — Thu, 25 Jan 2007 20:51:00 GMT

With the growing proliferation of Microsoft's ASP.NET AJAX, we are often asked by customers whether our CallBack control is intended as a replacement for UpdatePanel, or alternatively, whether UpdatePanel makes the CallBack control obsolete. To address these questions, I feel I should try to clear things up a bit.

CallBacks are simply different from UpdatePanels, and the two are not pitted against each other in any way (hence the question mark in the title of this entry). They are simply two different tools in the AJAX toolbox, if you will. The CallBack control can be thought of as a simpler, more light-weight tool.

UpdatePanels post the whole page, effectively performing a postback with each request. They do so asynchronously, so the original page stays put. The control then figures out which updateable areas of the page are affected by that postback (areas in UpdatePanels, essentially), and it redraws those areas, and updates ViewState. This mechanism preserves the old postback-based ASP.NET paradigm.

CallBack uses a different paradigm, simply letting you render some markup into a container, without posting the state of other controls (unless you want to). The rendering is not done via the usual ASP.NET mechanism, but through a server-side event handler, which determines exactly what gets sent back. Nothing else on the page can get modified, and ViewState is left untouched.

Long story short, you might want to use CallBacks for simple scenarios where all you want to do is write some stuff from the server onto the client based on a simple parameter. Also, by using CallBacks, you're not requiring the inclusion of the ASP.NET AJAX library, further optimizing things. If you are designing an application from scratch and want to be able to retrieve server-side content with client-side APIs, CallBack is a great tool to look at.

For scenarios where the postback paradigm needs to be preserved (eg. there are inter-control dependencies, state of controls inside the panel needs to be maintained, usual asp.net rendering should be used, etc), UpdatePanels are recommended.

Though the controls seem to do the same thing, we actually see them as complementing each other. They impose different paradigms and allow for different architectures, and depending on what the developer needs to accomplish, one is usually more appropriate than the other.

More choice can only be a good thing, I think!

Share this post: email it! | bookmark it! | digg it! | reddit!