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

0
Comments
979 Views

Toronto Code Camp 2008

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!

Posted by: Milos
Posted: Monday, March 03, 2008 11:07 AM
Filed under: ASP.NET AJAX, code camp, web services
0 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

10
Comments
6408 Views

New Grid Feature: Client-side Binding to Web Service

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!

Posted by: Milos
Posted: Wednesday, May 02, 2007 12:36 PM
Filed under: ASP.NET AJAX, ComponentArt Grid, 2007.1, JSON, Web Service
10 Comments

3
Comments
6559 Views

CallBack vs. UpdatePanel?

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!

Posted by: Milos
Posted: Thursday, January 25, 2007 12:51 PM
Filed under: ASP.NET AJAX, CallBack, UpdatePanel
3 Comments

1
Comments
2851 Views

Migrating Web.UI client-side code to AJAX Library syntax

The Web.UI 2006.2 release brings a brand-new client-side API that uses Microsoft’s AJAX Library syntax across the board: new property accessors, new naming conventions, a new client event mechanism, and more. The new API looks the same even in the non-ASP.NET AJAX builds, providing a way to future-proof your code even if you are not immediately moving to ASP.NET AJAX. Furthermore, everything has also been designed with backward compatibility in mind, so your old code will also work and nothing should break when you simply pop in the new assembly. It is highly recommended, however, that old client-side code which uses ComponentArt APIs be migrated as soon as possible to the new system. Here’s how: Accessing control objects With Web.UI 2006.2, it is no longer necessary to use the server-side ClientObjectId property to determine the client object ID in most cases. The only situation where this is still the case is when the control is in a repeated template, which results in its assigned ID not being unique. In that case, we still use the old way of referring to the client object by its unique ID: var myControl = <%= Control.ClientObjectId %>; In all other cases, simply using the assigned server-side ID will suffice. Regardless of how many nested containers the control is placed in (user controls, master pages, UpdatePanels, etc), it will use the assigned ID as its client-side object identifier if it is available. This makes it possible for the developer to write server-side and client-side code using the same identifiers in the vast majority of situations, never having to worry about hard-to-predict ID prefixes. Accessing properties One of the main differences between the old and new ways of doing things is how we access object properties. Every property now has its own get and, unless it is read-only, set methods. To get the value of an object's property, we call the object's get_propertyName method. For instance, to access TreeView's nodeCssClass property, we would call TreeView1.get_nodeCssClass() Similarly, when setting a property, we would use its set method. For example: TreeView1.set_nodeCssClass('NodeClass'); Batch updates In those cases where setting a property potentially affects the look of the control on the page, doing so will cause the control to re-draw itself. Multiple property sets may therefore cause unnecessary control re-draws, affecting performance. To avoid this, we notify the control that we are about to perform a batch of updates by calling its beginUpdate method. When the updates are done, a call to endUpdate causes the control to re-draw. Here is an example: TreeView1.beginUpdate(); TreeView1.set_cssClass('TreeClass'); TreeView1.set_nodeCssClass('NodeClass'); TreeView1.set_itemSpacing(3); TreeView1.set_marginWidth(15); TreeView1.endUpdate(); The beginUpdate and endUpdate methods are inherited from Sys.UI.Control and are a standard AJAX Library mechanism. Note that the render method is still present in controls that need occasional re-drawing, but it now rarely (if ever) needs to be called explicitly. Navigator node collections Navigation controls with client-side interfaces (Menu, TreeView, NavBar and TabStrip) now have collection classes for their items. These classes should be used to access menu items, tree nodes, etc. To access the collection of top-level Menu items, for instance, we no longer call the Items method – we would instead get its items property, which returns an object of type MenuItemCollection: var topItems = Menu1.get_items(); // get the top items var firstItem = topItems.getItem(0); // get the first item in the collection To add a new item, we no longer use the AddItem method – instead, we add the item to the appropriate collection. For instance, to add a new item to the first item’s sub group, we would do the following: firstItem.get_items().add(newItem); Calling methods By convention, method names now start with a lowercase letter. Therefore, in most cases, updating method calls to new syntax will require just that change. For instance, instead of calling Grid’s GetSelectedItems method to check which items are selected, we would use the lowercase equivalent: var selectedItems = Grid1.getSelectedItems(); Handling events Web.UI 2006.2 introduces a new way of defining client event handlers on the server. Each control with client events now has a ClientEvents property, which is an object containing all of that control’s client events and their handlers. For example, to handle NavBar’s itemSelect event on the client, we would no longer set its ClientSideOnItemSelect property. Instead, we would define the handler in the control’s ClientEvents block: < ComponentArt : NavBar runat = "server" ID = "NavBar1" ... > ... < ClientEvents > < ItemSelect EventHandler = "NavBar1_OnItemSelect" /> </ ClientEvents > </ ComponentArt : NavBar > Before Web.UI 2006.2, client-side event handlers had different signatures depending on the event. To comply with AJAX Library methodology, all event handlers now have the same signature: function eventHandler(sender, eventArgs) The first parameter, sender, is the control object which raised the event (for instance, a NavBar). The second, eventArgs, is an object of a class deriving from Sys.EventArgs and, depending on the event, contains various properties related to the event. For instance, NavBar’s itemSelect event passes a parameter of type NavBarItemEventArgs, which contains an item property, pointing to the NavBarItem involved in the event. To handle this event on the client, we might define a function that looks like this: function NavBar1_OnItemSelect(sender, eventArgs) { alert ('Selected item: ' + eventArgs.get_item().get_text()); } Conclusion That’s all there is to it! At any time now or in the future, check out the client-side API reference for further enhancements and additions. Happy translating! Share this post: email it! | bookmark it! | digg it! | reddit!