November 2007 - Posts

• 7 Comments 1963 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 7 Comments

  
  
  

• 1 Comments 965 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 1 Comments

  
  
  

• 0 Comments 1647 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! Posted by: Milos Posted: Tuesday, November 06, 2007 6:36 AM Filed under: Web.UI, SpellCheck, 2007.2 0 Comments