The Blog of Milos

This space is available to any ComponentArt employee to write about anything.

Browse by Tags

1
Comments
521 Views

Web.UI 2008.2 Grid News: Grouping

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!

Posted by: Milos
Posted: Tuesday, September 23, 2008 11:34 AM
Filed under: Grid, Web.UI, 2008.2, Grouping
1 Comments

4
Comments
1629 Views

Grid Configuration via Web Service

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!

Posted by: Milos
Posted: Friday, June 13, 2008 6:35 AM
Filed under: ASP.NET AJAX, Grid, AJAX, web services
4 Comments

5
Comments
1382 Views

New Grid Feature: CallbackParameter

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!

Posted by: Milos
Posted: Wednesday, December 19, 2007 3:26 PM
Filed under: CallBack, Grid, New Feature, CallbackParameter, Web.UI
5 Comments

8
Comments
2431 Views

New Grid Feature: WebService Running Mode

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!