The Blog of Milos

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

Browse by Tags

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

3
Comments
8177 Views

AJAX With ASP.NET MVC and ComponentArt CallBack

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!

Posted by: Milos
Posted: Thursday, May 01, 2008 11:08 AM
Filed under: CallBack, Web.UI, AJAX, mvc, ASP.NET MVC
3 Comments

8
Comments
2432 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!