Miljan Braticevic

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

Browse by Tags

32
Comments
51033 Views

A New AJAX Approach - Client-side Controls Invoking Web Services

Since the time we shipped our first production suite of native ASP.NET AJAX controls back in November of 2006, we've been experimenting with new ways of doing efficient incremental page updates. We felt that we had something promising on our hands with full fledged client-side controls. The ability to create high-level UI elements (menus, treeviews, grids, etc.) on the client seemed like a solid foundation to build on. Our research produced a new high-performance AJAX technique which is currently gaining quite a bit of momentum among our customers. I will explain how this technique differs from standard AJAX techniques, with comments on ease of use, performance, elegance and the available client-side features within each technique. I highly recommend trying the live examples associated to individual AJAX techniques below. Significant performance improvements are quite visible when the same functionality is implemented using different AJAX approaches. The final example is so fast that it truly feels like a local desktop application. Overview of Common AJAX Techniques Technique 1 - Server-centric AJAX Containers (ASP.NET AJAX UpdatePanel) The server-centric AJAX container technique is employed by the ASP.NET AJAX UpdatePanel control as well as several AJAX solutions sold by the leading 3rd party control vendors. UpdatePanels are driven entirely by ASP.NET postbacks. AJAX applications are created by wrapping postback-based ASP.NET portions of the page and specifying which triggers (server-side events) will cause certain page areas to re-render. Ease of use : The most obvious advantage of this approach is that it is extremely easy to implement. It is really not much harder than building a vanilla postback-based ASP.NET application and then wrapping certain areas of the page with UpdatePanels. This approach is ideal for quickly adding AJAX features to existing ASP.NET applications. Performance : The biggest downside of this approach is performance. UpdatePanels always post the entire page - including full viewstate - to the server. Even though the required AJAX update to the page is often minimal, its server-side page processing essentially takes the same resources as when doing a full postback. The response sends raw HTML back to the browser, adding kilobytes to the required network traffic to process the AJAX request. Elegance : The server-centric AJAX container technique is fairly elegant from the implementation point of view. Page areas are cleanly wrapped by UpdatePanel instances and AJAX updates are accomplished by mapping server-side events to triggers. All AJAX magic is performed by the UpdatePanel control itself. Features : All features exposed to the developer using the UpdatePanel control are entirely on the server side. The control was not designed to be driven by client-side logic. The server-centric approach lacks the finer level of control on the client, which is definitely needed to build sophisticated AJAX apps with hyper-responsive user interfaces. AJAX Explorer Example: Technique 1 - Server-centric AJAX Containers (ASP.NET AJAX UpdatePanel) Technique 2 - Client-centric AJAX Containers (ComponentArt CallBack) ComponentArt CallBack is similar to the UpdatePanel control in its high-level concept of acting as a generic AJAX container for ASP.NET content. Both controls allow rendering custom ASP.NET content (including server controls, user controls as well as literal content) through AJAX callbacks - without reloading the entire page. However, ComponentArt CallBack is driven entirely by its client-side API. Developers specify exactly when a callback will be triggered and exactly which parameters will be sent to the server (CallBack doesn't post the page by default). This triggers a server-side event, where the developer has full control over what will be rendered back to the client. Ease of use: ComponentArt CallBack is not as easy to use as the UpdatePanel control. It requires JavaScript code to initiate the callback request through the control's client-side API as well as implementing a server-side event handler to render content back to the browser. In most cases this amounts to just a few lines of code on the client and the same amount on the server. Performance : Requests made through the CallBack control are extremely lightweight in terms of network traffic. However, each request has to go through the full page life cycle and the response typically generates HTML and sends it back to the browser. Elegance : The CallBack control hooks into the page life cycle and exposes the native ASP.NET object for rendering (HtmlTextWriter) to the developer. While the developer needs to write custom code both on the server and the client to perform an AJAX request, the level of control that is gained makes it worthwhile in most cases. Features : The client-centric AJAX approach exposes more capabilities to rich web applications with highly-responsive user interfaces because all AJAX request decision-making logic resides within the client-side event-driven code. AJAX Explorer Example: Technique 2 - Client-centric AJAX Containers (ComponentArt CallBack) Technique 3 - Manual JavaScript Coding Against Server-side Logic (Ajax.NET, ASP.NET 3.5 Script Services) The previous two techniques revolve around the ASP.NET page model and are essentially delivered as ASP.NET server controls. In contrast with these techniques is a pure JavaScript approach originally introduced by Michael Schwarz with his Ajax.NET library. The core idea is to provide a way to mark methods of any server-side class with the "[AjaxMethod]" attribute and then be able to invoke that method from client-side code. A similar technique is available with ASP.NET AJAX/3.5, which makes it incredibly easy to expose a web service and invoke it directly from client-side code. Significant performance improvements of this approach over the previous two are probably the main reason for its incredible popularity within the development community. Ease of use : Invoking server-side logic on the client is easy with Ajax.NET / ASP.NET 3.5. However, this solution assumes quite a bit of manual JavaScript coding in order to generate and update user interface elements of the page. This is why it doesn't get high marks in the "ease of use" category. Performance : There are two important performance breakthroughs of this approach: 1) Since methods of any class can be invoked through client-side code, the server-side request processing doesn't need to go through the ASP.NET page life cycle. The client-side request hits exactly the method it needs and it receives exactly the response it needs. There is no waste of server resources. 2) The response doesn't contain HTML markup. Rather, it contains only the data requested by the client. This can reduce the network traffic required to process the AJAX request by an order of magnitude. The received data is used on the client side to generate or update user interface elements. Elegance : All functionality included with Ajax.NET or ASP.NET 3.5 Script Services is well architected. However, the overall solution is missing a piece of the AJAX puzzle and this is the reason why this approach loses points in the "elegance" category. The fact that developers are stuck with generating the user interface layer leaves the application with quite a bit of JavaScript code to maintain. Features : The Ajax.NET library as well as ASP.NET 3.5 Script Services are loaded with client-side features. They contain the ability to easily invoke server-side logic as well as serialize .NET objects to their JSON representations. They don't, however, have the ability to manipulate high level UI elements (menus, treeviews, grids, etc.). AJAX 2.0 - Client-side Controls Invoking Web Services The new AJAX approach builds on best performance practises presented in the previous technique: efficiently executing server-side logic by invoking ASP.NET 3.5 web services and only sending data over the network. However, instead of requiring manual JavaScript coding to create and manipulate user interface elements, this functionality is now built into ComponentArt Web.UI client controls. Ease of use : High-level client controls expose API methods to invoke web services. The structure and content of those controls is automatically populated with the results returned by the web service and the update is immediately visible on the screen. Even though some client-side coding is required to create and maintain user interface elements, it is reduced from many hundreds of lines to just a handful of high-level API calls. Not as easy as using the UpdatePanel control, but pretty close. Performance : As already stated, this approach builds on best performance practises presented in the previous technique. However, the overall performance of an application built with this new approach actually exceeds the previous one. Additional performance improvements come from extensive client-side UI generation optimizations that we've built into the ComponentArt Web.UI suite. Elegance : A high-level description of this technique is simple and powerful: "Objects on the client (client-side controls) communicate directly with objects on the server (web services)". The server-side logic of the application is delivered as a collection of web services - without any preconceived user interface decisions. This produces a real separation of tiers and greater code reuse options. Those web services could potentially be reused by multiple types of applications: mobile, smart client, Silverlight or other ASP.NET apps. Features : Not only is AJAX request decision-making logic in the same domain as the rest of the app, but it is transparent to it. Updating a portion of the user interface through a fast AJAX request is no different than invoking any other client-side API method. AJAX Explorer Example: Technique 4 - Client Controls Invoking Web Services Summary The new AJAX technique presented here is an evolution of the previously available techniques, rather than a radical departure from them. It builds on the strengths of AJAX best practises, while introducing something new: full fledged client-side controls capable of communicating directly with web services. It's important to note that there is no clear winner for all application scenarios. All of these techniques deserve consideration, depending on the specific situation. For example, ASP.NET AJAX UpdatePanels might end up being chosen for apps that run on fast internal networks. Client-controls invoking web services are a great option for high-performance apps with rich and responsive user interfaces. Mixing various techniques within the same application is also a perfectly viable strategy. Share this post: email it! | bookmark it! | digg it! | reddit!

Posted by: Miljan
Posted: Friday, January 25, 2008 9:29 AM
Filed under: AJAX, ComponentArt, ASP.NET AJAX, XML, ASP.NET 3.5, AJAX 2.0, JSON, Web.UI, Web Services
32 Comments

52
Comments
15286 Views

Finally! ComponentArt Editor for ASP.NET AJAX

Without any doubt, the upcoming Editor control is the most anticipated product ever developed by ComponentArt. Our customers have been telling us for years that they are unhappy with existing solutions on the market, and that we should make a ComponentArt-quality browser-based WYSIWYG editor. We set out to do that about a year ago, and I am happy to announce that we are approaching the first public beta release. Building a solid browser-based text editor is hard. Our research has uncovered fundamental problems with various ASP.NET editing controls as well as major online document editing services like Google Docs. I will talk about our unique approach to the problem as well as share some interesting things we learnt along the way. How Browser-based Editing Works Modern browsers have built-in rich text editing features. Developers can take advantage of those features by simply adding an IFrame to a page and setting its document.designMode property to "on". This enables editing of the IFrame's content and provides many basic editing features "for free". However, there are vast inconsistencies among the browsers in the way that editing is handled. Consider the following minimal fragment of text: First some bold text , then some italic text , then a change of color . Finally, a new paragraph! Let's review the markup generated by various browsers when this piece of rich text is entered. Internet Explorer 6-7: First some bold text, then some italic text, then a change of color. Finally, a new paragraph! Firefox 1-2: First some bold text, then some italic text, then a change of color. Finally a new paragraph! Ouch! Not only is the output from IE and Firefox entirely different, but neither is XHTML-compliant. Let's try the other two leading browsers... Safari 3 (beta): First some bold text, then some italic text, then a change of color. <div>Finally a new paragraph!</div> Safari seems to do the best job so far - the generated markup is XHTML-compliant. However, why is the second paragraph contained in a DIV, but not the first? Also, what's with those Apple-style-span CSS classes? Let's look at Opera... Opera 9: First some bold text, then some italic text, then a change of color. Finally, a new paragraph! We have found that the currently available web editors (including ASP.NET controls as well as online document editing services) deal with these inconsistencies with varying degrees of success. However, we haven't found a product that always natively produces cross-browser-consistent, XHTML-compliant markup - without the need to run additional clean-up and conversion utilities. Our Approach Let's repeat this mantra one more time: "Create an editor control that natively produces cross-browser-consistent, XHTML-compliant markup - without the need to run additional clean-up and conversion utilities." In order to accomplish that, we had to take over the control from the browser and write a custom XHTML serializer whose responsibility is to generate the document in response to user commands. That task is not trivial. It essentially amounts to writing a text editor in JavaScript from scratch, since we are no longer getting freebies from the browser. It was a lot of work, but we think it was worth it, as it brings additional important advantages beyond the purity of the generated content: 1. Completeness and power of the client-side API . Having full control over not only the markup, but the code that generates that markup allows us to expose a pretty powerful API to the developer. This API includes the same methods (for things like applying styles, getting/setting selections, controlling the structure of the document, etc.) as those used internally by the Editor control itself. In line with the rest of the Web.UI suite, Editor's API is based on the client-side component model introduced by ASP.NET AJAX. More info on the API will be coming soon from members of the Web.UI development team. 2. Ease of extensibility . Our solution consists of a lightweight, standalone Editor box (which can be used without any decoration) and the UI (toolbars, menus, tabs, dialogs, etc.), built entirely through our native Web.UI controls. The Editor box and the UI controls are "tied" together through their public APIs. This means that developers can create custom UIs to drive the Editor control using exactly the same techniques we did. Custom UIs are not only possible; they will be treated as "first class citizens" by our Editor control. 3. Customizable document styles . This is one of my favourites. Separated from Editor UI skinning, developers are also able to customize the styles that will be used for the document content. This includes things like paragraph and heading styles, bullet and number list styles, custom CSS classes and style strings that will be available in the style dropdown, as well as the collection of custom colours that will be added to the colour picker. In a nutshell, this feature enables developers to provide their end-users with a convenient collection of style elements that will fit into the target theme. A Glimpse of this feature can already be seen in the two demos below. 4. Ability to control all aspects of the document . For example, we can allow customizing the line breaking style: developers should be able to specify whether they prefer , <div></div> or elements for breaking. Finally, adding other new features is fairly easy, now that we have a solid core engine in place and full control of the document as well as the serialization logic. For example, Word paste clean-up can now be easily done, as stripping unwanted tags is simply an option in our serializer. Live Demos We are happy to provide a sneak preview of ComponentArt's Editor control in action: - "Black Ice" Skin - "Arctic White" Skin Please be advised that this is a pre-beta quality product, so it is still rough on the edges, and its functionality will not be entirely stable. I should also say that these demos don't show off all Editor features - they contain only minimal toolbars and no dialogs. Next Steps We are currently alpha testing the 2007.2 release with a small group of select customers. If you run into any bugs while using the demos above, please send the exact steps for reproducing each problem directly to beta@componentart.com . We are planning to ship a public beta release at the beginning of October, and the full 2007.2 release in mid November. As always, these dates are based on our best estimate and are subject to change. This release has been a long time coming, but we hope you'll find that it was worth the wait! Update : We have just shipped the public beta of Web.UI 2007.2, which can be accessed through our beta download page . You will need to be logged into your ComponentArt profile and signed up to the beta program to access the download package. Among other things this build includes two new skins: - "Office 2003" Skin - "Web Ribbon" Skin The last one is my personal favourite. I hope you'll like it too. Share this post: email it! | bookmark it! | digg it! | reddit!

Posted by: Miljan
Posted: Thursday, September 13, 2007 1:48 PM
Filed under: AJAX, ASP.NET AJAX, Rich Text Editor, WYSIWYG Editor, ASP.NET Editor
52 Comments

2
Comments
2242 Views

ComponentArt Web.UI 2007.1 Details Announced

Last night we updated the official Web.UI product roadmap . We are about 1-2 weeks off target regarding the release dates that were announced back in November. However, the good news is that the 2007.1 release will include one additional control (Dialog for ASP.NET), adding a total of three new controls: ComboBox, ToolBar, and Dialog. Adding a third control won't be the only surprise with the 2007.1 release. We are about to deliver a set of features that will take the built-in AJAX capabilities of ComponentArt Web.UI to the next (and yet unseen!) level of richness. We are very excited about this aspect of the 2007.1 release. I won't reveal any more details at this time, as these types of features are always best seen in a live demo. Share this post: email it! | bookmark it! | digg it! | reddit!

Posted by: Miljan
Posted: Thursday, February 01, 2007 7:49 AM
Filed under: AJAX, ASP.NET AJAX, ComponentArt Web.UI, JavaScript
2 Comments

1
Comments
9917 Views

Ditch That Beta Sign Eugene, We're Going to Production!

The final version of ASP.NET AJAX was released today. We are very pleased to simultaneously announce the immediate availability of the full production version of ComponentArt Web.UI for ASP.NET AJAX. Taking those "beta" signs off our ASP.NET AJAX product line felt really good! Developing for various technology preview and beta builds of "Atlas" / ASP.NET AJAX has been quite an experience. It all started at the PDC 2005 conference where Microsoft showed off the first prototypes of their new framework. I remember that Phil , Jovan , Milos , and myself were there, but we were not allowed to enter Nikhil's presentation on Atlas because we were exhibitors and had only one attendee pass. We sat on the floor just outside of the conference room, where we were sort of able to follow the presentation on one of the screens. In the coming months we were thinking hard about our role as a component vendor, and the best way to add value to the platform. We were very impressed by the early CTP builds of Atlas, so we made a somewhat risky move to put most of our development resources on building a suite of UI controls for a framework that hadn't even reached the beta stage. Our assessment was that the release of Atlas would be a game-changing event of magnitude comparable to the release of ASP.NET itself. That decision meant developing against a (rapidly) moving target. Microsoft promised that they would change designs and implementation details on the go, and they sure kept that promise. One of the most drastic shifts was the famous Beta 1 release. I blogged about our experience upgrading to Beta 1 here . Developing against such early builds of a framework is not a simple task, not only because things tend to change a lot, but also because resources are so incredibly scarce. You can't buy a book and learn all about it. Forget about handy reference manuals. In the early days, our only resources were blogs of various dedicated Atlas team members, as well as the source code of the product itself. Somewhere in the middle of 2006 ComponentArt became a part of the "ASP.NET AJAX Develop Program", designed to engage early adopters of this technology. We were able to attend various technical sessions in Redmond, as well as get preview builds of the framework well before they were available to general public. Yes - we finally got our revenge. Take that, Mr. PDC05 security officer! The flip side of all the challenges was a highly rewarding sense of accomplishment as we saw things come together in the last quarter of 2006. We were determined to bring something new and significant to this changing market, and to try to ship at the same time as the framework itself is released. The result of our work is the industry's first commercial suite of UI controls built on top of the ASP.NET AJAX component model. The client-side capabilities and the level of client-side programmatic control offered by ComponentArt Web.UI for ASP.NET AJAX far exceed that of any UI library (for any framework) that we are aware of: - Watch the Web.UI for ASP.NET AJAX Video We are very excited about ComponentArt's unique position in the AJAX space. Instead of creating yet another proprietary AJAX framework that duplicates functionality found in ASP.NET AJAX, we have embraced Microsoft's new technology and created something that every AJAX framework needs: true client-side UI controls. Starting today, our customers have a best-of-breed AJAX development framework in ASP.NET AJAX, and best-of-breed UI controls in ComponentArt Web.UI for ASP.NET AJAX. This is a truly exciting moment! Share this post: email it! | bookmark it! | digg it! | reddit!

Posted by: Miljan
Posted: Tuesday, January 23, 2007 9:56 AM
Filed under: AJAX, ASP.NET AJAX, ComponentArt Web.UI, JavaScript
1 Comments

8
Comments
18231 Views

"Interoperability" vs. "True ASP.NET AJAX Controls"

"Interoperability" is a term that has been used by several ASP.NET control vendors, including ComponentArt, to describe integration with ASP.NET AJAX. However, since we shipped the first public beta release of Web.UI for ASP.NET AJAX, we started using new verbiage to describe our product offering: "True ASP.NET AJAX Controls". Is this just marketing spin? Is there some technical backup for these claims? Finally, as an ASP.NET AJAX developer, why should you care? I'll try to explain the meaning of these terms, and let you draw your own conclusions. Interoperability Providing interoperability with ASP.NET AJAX essentially means that the controls won't break when used with ASP.NET AJAX. Specifically, they will operate as expected when nested inside the new UpdatePanel control, and they won't **interfere** with the ASP.NET AJAX client-side JavaScript code. However, controls that provide interoperability with ASP.NET AJAX are actually native ASP.NET 2.0 controls, tweaked so they can co-exist on the same page with ASP.NET AJAX. They don't have any ASP.NET AJAX dependencies and don't really take advantage of ASP.NET AJAX features. Providing this level of support for ASP.NET AJAX is definitely the first step in targeting Microsoft's new web development framework. ComponentArt originally started providing interoperability with ASP.NET AJAX (or "Atlas") back in May of 2006 with Web.UI 2006.1 SP2. True ASP.NET AJAX Controls There is much more to ASP.NET AJAX than the UpdatePanel control. Actually, the most significant aspect of ASP.NET AJAX is that it introduces a real framework for JavaScript development, including a comprehensive model for creating client-side components and controls. ComponentArt Web.UI for ASP.NET AJAX is the first commercial control suite built on top of this new component model. Having user interface controls that allow complete client-side programmatic manipulation opens up a world of possibilities. What's more important, these client-side capabilities are exposed in a standardized way, which is supported by Microsoft, and guaranteed to work with ASP.NET vNext, and Visual Studio Orcas. Watch the Video The difference between "interoperability" and "true ASP.NET AJAX controls" is explained quite well in the video we recently published. If you have 5 odd minutes to invest into perhaps getting a deeper understanding of the subject by seeing some of this functionality in action, then I highly recommend it: - Video: ComponentArt Web.UI for ASP.NET AJAX I think the following quote by a seasoned industry veteran sums it up quite well: "Writing the code you show in the video has been my dream for 7 years now. Since the time I saw a very early demo of what was then called ASP+. " Dino Esposito Author, Speaker, and Columnist for the MSDN Magazine Thank you Dino. It has been our dream too. :) Share this post: email it! | bookmark it! | digg it! | reddit!

Posted by: Miljan
Posted: Monday, January 08, 2007 9:42 AM
Filed under: AJAX, ASP.NET AJAX, ComponentArt Web.UI, JavaScript
8 Comments

0
Comments
2199 Views

ComponentArt Web.UI 2006.2 SP2 - Now Supporting the ASP.NET AJAX Release Candidate

The ASP.NET team shipped the release candidate for ASP.NET AJAX 1.0 late last week. According to Scott Guthrie, "the next public release will be the final, fully supported, 1.0 product", and the final release is expected in about 4 weeks. We have been working with the ASP.NET AJAX RC build for just over a week, and I am pleased to announce the immediate availability of ComponentArt Web.UI 2006.2 SP2 (build: 2006.2.1498) which targets the ASP.NET AJAX Release Candidate. The latest build is available from the main Web.UI download page . Share this post: email it! | bookmark it! | digg it! | reddit!

Posted by: Miljan
Posted: Monday, December 18, 2006 3:36 PM
Filed under: AJAX, ASP.NET AJAX, ComponentArt Web.UI
0 Comments

0
Comments
3203 Views

Video: ComponentArt Web.UI for ASP.NET AJAX

We have just published our first video: ComponentArt Web.UI for ASP.NET AJAX . One of the main things we show in this video is how our Web.UI controls utilize the new client-side component model introduced by ASP.NET AJAX to bring more capabilities to client-side coding. We hope that you will find it interesting and informative! Share this post: email it! | bookmark it! | digg it! | reddit!

Posted by: Miljan
Posted: Friday, December 08, 2006 12:10 PM
Filed under: AJAX, ASP.NET AJAX, ComponentArt Web.UI, Video
0 Comments

5
Comments
15062 Views

ASP.NET AJAX and ComponentArt Web.UI Product Direction

We recently shipped Web.UI 2006.2 . The second major release of Web.UI this year includes a brand-new platform build: Web.UI for ASP.NET AJAX. However, no new controls were added to the suite this time around. I would like to take this opportunity to provide additional background information, as well as explain why we think that our direction will bring maximum value to our customers. A Brief Walk Down Memory Lane Nearly five years ago Microsoft reshaped web development with the release of ASP.NET. This was a powerful new server-centric development framework, drastically different from its predecessor - ASP. One of the most interesting new concepts introduced with ASP.NET were server controls: reusable pieces of web logic and UI that developers could easily include in their pages and program against - in a very natural, object oriented, and event driven way. Even though a fair number of good server controls shipped in the box with v1.0 of ASP.NET, this new technology sparked an explosion of 3rd party component development. There is a number of companies that successfully add value to the platform by building ASP.NET server controls today. The Introduction of ASP.NET AJAX We think that web development is about to be reshaped again. Driven by consumer demand for richer and more responsive web experiences, Microsoft has created a comprehensive client-side framework: ASP.NET AJAX . The core portion of ASP.NET AJAX includes: a JavaScript type system, a networking and JSON serialization stack, AJAX server controls for partial page rendering, application services features (profile & authentication), a client-side application model, and - of particular interest to us - a model for creating client-side components and controls. So, what does all of this mean to an ASP.NET developer today? The upcoming release of ASP.NET AJAX will be a significant event for all ASP.NET developers because it introduces a real framework for client-side development. This framework will come with powerful baseline features and it will be fully supported (ASP.NET AJAX comes with Microsoft's standard 10 year, 24-7 support license). Having a standard client-side framework opens up a world of possibilities. Things like calling a web service from your JavaScript code, serializing a server-side object for manipulation on the client, or doing partial page rendering through AJAX callbacks will all become mainstream web development techniques. This will change the responsiveness and the feel of ASP.NET applications in a profound way. In contrast to the big paradigm shift from ASP to ASP.NET, buying into the latest web technology won't require rewriting your applications from scratch this time around. On the contrary, ASP.NET AJAX was designed to work on top of ASP.NET 2.0. It is extremely easy to incrementally add richness to your existing apps by simply including a reference to the ASP.NET AJAX assembly and applying the new features on selected pages. The ASP.NET AJAX UpdatePanel control is particularly handy for converting existing postback-based pages to the more efficient AJAX-style model. Finally, one of the most exciting aspects of ASP.NET AJAX is the new model for creating client-side components and controls. A unified way of defining classes, namespaces, object properties, methods, and events, combined with the included base classes (Sys.Component and Sys.UI.Control) brings structure and form to JavaScript code reuse. Much like server controls introduced with ASP.NET, ASP.NET AJAX client-side components have the potential to significantly boost developer productivity and bring a whole new set of features to the mainstream. ComponentArt Web.UI for ASP.NET AJAX Recognizing this new opportunity, ComponentArt has invested considerable resources over the past year to develop new web user interface technology that can truly take advantage of the advanced features that ASP.NET AJAX offers. As a result of this work, ComponentArt Web.UI 2006.2 introduced industry's first suite of UI controls built on top of the ASP.NET AJAX client-side component model. These controls expose extensive client-side APIs, and feature a unique ability to be programmatically modified on the client. This means that adding / removing / modifying menu items, treeview nodes, grid rows, etc., is now possible on the client - with immediate refreshing of the screen. Of course, client-side controls always live in the context of a server-side web application, so all client-side changes have to be automatically persisted to the server-side object state when a postback or a callback occurs. We consider this to be a significant step forward in extending the richness of web applications. A whole new class of operations no longer require roundtrips to the server, which dramatically improves application responsiveness and user experience. Our goal was to deliver the richest set of controls that are truly built for ASP.NET AJAX from the ground up. The initial industry feedback we have received has been overwhelmingly positive, which leads us to believe that we are on the right track. Adding New Controls to the Web.UI Suite The magnitude of the work needed to develop the new user interface technology described above has slowed down the pace of adding new controls to the suite. However, we are now quite happy with where we stand in terms of core technology, and we are focusing on building new Web.UI controls. The initial set of controls to be added to the suite is outlined on our Web.UI product roadmap page . That's just the beginning; we will continue to rapidly add new controls (as well as extend the baseline feature set of the existing controls) throughout next year. It should be noted that applying our existing technology to develop new controls is now fairly routine work, involving significantly less risk than the work we have done to develop the technology itself. Immediate and Long-term Value for Customers Staying With ASP.NET 1.x The new client-side API described above is also available with Web.UI 2006.2 for ASP.NET 1.0. The API is accompanied with our new state-of-the-art client-side API reference , which is also available for all platform builds. Finally, as stated on our product roadmap, new controls will be added to all three platform builds simultaneously. Therefore our customers who don't immediately embrace ASP.NET AJAX will not be left behind. Conclusion If you haven't had a chance to try out ASP.NET AJAX yet, we encourage you to do so, especially if you are already using ASP.NET 2.0. The framework is now feature complete, has a stable API, and its full release is expected by the end of the year. It's a great time to get a head start on the next big wave of Microsoft's web development technology. We believe that with the imminent release of ASP.NET AJAX and ComponentArt Web.UI for ASP.NET AJAX, our customers will have the most powerful set of tools for building rich web applications available anywhere. As always, your feedback is welcome and appreciated. Share this post: email it! | bookmark it! | digg it! | reddit!

Posted by: Miljan
Posted: Wednesday, November 15, 2006 9:39 AM
Filed under: AJAX, ASP.NET AJAX, ComponentArt Web.UI, JavaScript
5 Comments

13
Comments
10618 Views

ASP.NET AJAX Beta 1 and ComponentArt Web.UI

We have recently completed converting our suite of user interface controls from the latest Community Technology Preview "Atlas" build to ASP.NET AJAX Beta 1 . The Beta 1 release of ASP.NET AJAX is significant because it closely resembles what is soon going to be released as the official version 1.0 of the product. However, it does introduce some breaking changes from the CTP versions. I'll tell you about our experience, and give my thoughts on the state of Microsoft's new AJAX development framework. Just to put things in perspective, our product consists of 12 UI controls that encapsulate common user interface elements (menus, trees, grids, etc.) exposing over 60 client-side classes built on top of the AJAX Library type system. For more information, visit the live demos or the client-side API reference . After getting over the initial hump, we found ASP.NET AJAX Beta 1 to be remarkably well functioning and stable. Virtually every issue we ran into while converting our Web.UI library and samples to ASP.NET AJAX Beta 1 had to do with our own lack of understanding of how a particular feature works. Judging by what is being said about ASP.NET AJAX Beta 1 in some blogs and forums, it appears that other people are in a similar situation. Unfortunately, some of them are concluding (incorrectly, I think) that the product itself is buggy. My impression is that Beta 1 is a significant step forward from the CTP versions, and that it is starting to feel like a production-quality release. For clarity, I will talk separately about converting the core Web.UI library and the live samples application. Most people who have written applications based on a CTP version of "Atlas" will only need to deal with the latter. Converting the Core Web.UI Library We addressed the following changes while converting from CTP "Atlas" bits to ASP.NET AJAX Beta 1: 1. Class definitions through prototypes instead of closures . One of the biggest changes in Beta 1 is that prototypes are now being used to define JavaScript classes (more info on Bertrand Le Roy's excellent blog: part 1 , part 2 ). We were actually already using prototype-based class definitions with CTP builds of "Atlas", so no changes were necessary here. So far so good! 2. The new model for client-side events . The old syntax for assigning events on the client was: object.eventName.add(eventHandler); The new syntax is: object.add_eventName(eventHandler); object.remove_eventName(eventHandler); For example: TreeView1.add_nodeSelect(TreeView1_onNodeSelect); So, instead of having event objects with add/remove methods, we now have add_eventName and remove_eventName methods on the main object directly. Another related Beta 1 addition is the "events" collection on the Sys.Component base class. We went ahead and applied these changes across the board. 3. The exclusion of type descriptors from the core product . Type descriptors provide the ability to discover type characteristics of a client-side object at runtime. You can use type descriptors to get the list of properties, methods, and events of an object, along with other applicable meta data. To support this functionality, an AJAX Library class needs to implement the Sys.ITypeDescriptorProvider interface. We had this implemented for all of our client side classes. Since type descriptors were primarily designed to support xml-script, and Microsoft decided not to make xml-script a part of the core v1.0 product (it is still available in the "value add" portion), type descriptors were also moved to the "value add" bucket. This was probably the biggest disappointment for us when it comes to Beta 1 changes. We found type descriptors to be universally useful, and - even though they were not originally designed to provide reflection - they still give the ability to discover the structure of an object at runtime, which enables some really elegant generic code. Since our decision was not to make any required dependencies on "value add" functionality, we ended up implementing our own rudimentary reflection for all Web.UI client-side classes. Of course, if a customer of ours does include the "value add" portion of ASP.NET AJAX in their app, they will get support for type descriptors as expected. 4. Support for the new and improved UpdatePanel control . When we first tried the Beta 1 build with Web.UI, none of our controls worked with the new version of the UpdatePanel control. This was pretty depressing for a few minutes, until we remembered what was said at the Atlas Strategic Design Review lab we attended back in August. Client scripts now have to be registered through the ASP.NET AJAX ScriptManager object (as opposed to the ASP.NET Page object). More info on this change was posted by the developer of the UpdatePanel control Eilon Lipton here . I really like the new version of the UpdatePanel control. I will try to blog about that separately soon. Converting the Live Samples Application In comparison to the work described above, converting the live samples application was an easy and routine exercise. My guess is that most developers who have built applications based on CTP bits of "Atlas" should be able to follow similar steps and get to the finish line fairly quickly. Here is what we did: 1. Removed the old Microsoft.Web.Atlas.dll project reference, and added a reference to the new Microsoft.Web.Extensions.dll , which is now installed in the GAC; 2. Added a reference to the new ComponentArt.Web.UI.dll , build 2006.2.1470.3; 3. Changed the <atlas: tag prefix to <asp: ; 4. Applied the following API changes to all UpdatePanel instances: a. Changed the Mode property to UpdateMode ; b. Changed all EventTrigger entries under the Triggers section to AsyncPostBackTrigger . At this point we were able to compile the app. 5. Then we changed all $ JavaScript calls to get$ . In order to play nicely and not cause collisions with other frameworks, Microsoft has decided to rename the $ function to $get. This function essentially evaluates to document.getElementById, making it easier to get instances of DOM objects in your code. That was it! The entire conversion effort took about 4 days, which really isn't bad considering the size of our product. Without any doubt, there is a lot of room for improvement of documentation, samples and tutorials for the upcoming ASP.NET AJAX releases. Maybe more than the core framework itself. The really good news is that all of the big changes are already included in the product, so it's a great time to start developing with ASP.NET AJAX! I would be curious to hear about your experience with ASP.NET AJAX Beta 1, especially if you are using ComponentArt Web.UI. Share this post: email it! | bookmark it! | digg it! | reddit!