The Blog of Milos

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

Browse by Tags

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

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

3
Comments
6558 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!