The Blog of Milos

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

Browse by Tags

1
Comments
523 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

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

4
Comments
1281 Views

TreeView and Web Services

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!

Posted by: Milos
Posted: Wednesday, April 23, 2008 10:49 AM
Filed under: Web.UI, treeview, web services, Load on demand
4 Comments

4
Comments
1907 Views

Web.UI Navigation Controls and Web Services

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!

Posted by: Milos
Posted: Tuesday, April 01, 2008 10:45 AM
Filed under: Web.UI, web services, custom parameter
4 Comments

3
Comments
2001 Views

Introducing ComponentArt Upload

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!

Posted by: Milos
Posted: Friday, March 28, 2008 5:21 AM
Filed under: Web.UI, Upload
3 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

0
Comments
1103 Views

Web Service Data Loading with Navigation Controls

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!

Posted by: Milos
Posted: Tuesday, December 18, 2007 8:18 AM
Filed under: ASP.NET AJAX, Web Service, Web.UI, navigation, treeview
0 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!

Posted by: Milos
Posted: Wednesday, November 14, 2007 8:30 AM
Filed under: Web Service, Grid, Web.UI, AJAX
8 Comments

2
Comments
1127 Views

SpellCheck Client-side API

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!

Posted by: Milos
Posted: Wednesday, November 07, 2007 10:55 AM
Filed under: Web.UI, SpellCheck, API, client-side
2 Comments

0
Comments
1832 Views

Introducing SpellCheck

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!