MSDN Notes: Implementing the CLR Asynchronous Programming Model (Jeffrey Richter)

Source: http://msdn.microsoft.com/msdnmag/issues/07/03/ConcurrentAffairs/

1.       Introduction

a.       For applications that require interaction with IO, the answer is often to write into the solution more threads – this still incurs an overhead, however, in terms of the operating system resources needed to spawn and manage threads.

b.      The better solution, according to this article, is to use the CLR’s Asynchronous Programming Model (APM) in lieu of the a more heavily threaded application.

c.       There are four main reasons, according to this article, why you would write a class that implements the APM.

                                                               i.      You’re building a class that directly interacts with hardware,

                                                             ii.      You might be building an abstraction layer atop a class or code base that already talks to hardware,

                                                            iii.      You may have long-running methods in your class,

                                                           iv.      You might be wrapping non-asynchronous Win32 functions.

2.       The heart of the APM: IAsyncResult

a.       Any class implementing APM has a Begin/End method (ex: BeginRead/EndRead) pair of methods. The Begin version must create and return an Iasyncresult object that is the center of APM model.

                                                               i.      The object can be queried for the status of the asynchronous operation and is used to determine the result when the operation is completed.

b.      IAsyncResult has a property – a wait handle – that is actually ineffecient to use and so ought to be avoided if at all possible (many asynchronous operations will have a callback anyway, signalling the end to the operation).

 

 

 

I'm not sure if this has been done before, but it might prove to be another way cross-site scripting is dangerous.

Right now I'm trying to create a global index of all corporate blogs on my new site www.blogsbycompany.com. I'm waaay off the target now, but it's a pet project I'm playing with at the moment (don't bother going to it - yet). Regardless, I'm seeing that people put HTML into their RSS feeds; I'm noticing it all over the place (and it does make sense). My site aggregates company blogs (I have about 8 thousand blogs right now - but, I'm not advertising the site because it's way off of where I want it), but I'm noticing that sometimes I get encoded JavaScript in my blog descriptions (I'm making sure that people are properly encoding the script or else I encode it for them before displaying it in the results page on my search site).

What this tells me is that if someone out there is poorly doing a web bot or a RSS aggregator site, they could potentially open their viewers up to someone running script in the browser or on the cilent through RSS feeds. Most people simply expect the RSS content to be nicely formatted, but if they foolishly try to decode script, they could really cause some damage to their readers.

Most people who first start toying around with ASP.NET AJAX experience the coolness of using the UpdatePanel in their projects to cleanly update portions of their page. The end result is cool, the ease by which you can get at the result is cool and, well, everything about the experience is pretty cool.

However, the ease and coolness factor come at a price - effeciency and finely grained control. For, I would think, about 70% of your development needs this is okay – given that most of what you’ll be using AJAX for is simple region refreshes, etc. However, there are those situations where you might need a bit more from your AJAX framework, and if that’s the case, you should have a look at the WebRequest (Sys.Net.WebRequest) class.

Sys.Net.WebRequest is a client-side class (therefore written in ECMA script) that is the foundation for all asynchronous web requests that occur in ASP.NET AJAX (the UpdatePanel uses it, for example). The nice part is that it, itself, is a nicely consumable class that is easy to understand and quick to use.

Here’s is a quick run down on how to use the class.

First, you instantiate the class in your script code:

var wRequest =  new Sys.Net.WebRequest();

Then you set the URL which will be involved in the asynchronous web request.

wRequest.set_url(getPage);

Next, you set the very (GET or POST):

wRequest.set_httpVerb("GET");

Then you set the “user context”. This is a value of any kind that differentiates the response from one asynchronous request from another. The WebRequest class will attempt to complete the request asynchyronously and call a registered callback when it’s done – this contextual information will let you know to which request the callback is registered.

wRequest.set_userContext("user's context");

You then assign the compelted event handler:

wRequest.add_completed(OnWebRequestCompleted);

And fire off the request:

wRequest.invoke(); 

The first argument of your callback method “OnWebRequestCompleted” is a XmlHttpExecutor object that you can use to retrieve information about your request.

More information about WebRequest

More information about XmlHttpExecutor.

 

1. This is a solution to be noticed by developers of add-ins or languages leveraging Visual Studio,
2. It has two variants: the "integrated" and "isolated" modes. If you build tools or languages that run within Visual Studio standard editions, then "Integrated" mode is your mode. If you wish to create a solution that leverages the core features of Visual Studio but isn't branded as Visual Studio, then "isolated" is your mode.
3. In Isolated mode, end-users of our product are not required to have Visual Studio on their machines, with Integrated mode they are.

Therefore it's a framework for building applications that integrate into Visual Studio or use the core feel of Visual Studio as a foundation for an entirely new and unrelated product. Definitely something worth checking out if you have an interest or commitment in developer tools. Have a look here..

There seems to be a lot of confusion out there with regards to getting the ENTER key to submit a form. I'm here to tell you that the best solution I have found (and the one I use) is to drop whatever TextBox controls I'm using and the final Submit button into a panel control, and then set the DefaultButton property of the panel to the button to be clicked when ENTER is pressed. For example:

<asp:Panel ID="Panel1" runat="server" DefaultButton="Button_Search" Height="50px"
        Width="329px">

When focus is in a TextBox control inside the Panel and the ENTER key is struck, Button_Search will be "clicked" or invoked by the browser to post back the form data. The result is the feel of google's search engine where you simply type in the text box and hit ENTER to start the search.

A default button can also be supplied for the Form object itself, and this is set as a property on the form object too.

One thing to note is that the default behavior when a form is submitted through an ASP.NET button control is that the __EVENTTARGET or "source" of the form post is set to nothing. For example, by clicking a submit button manually, the Form variables posted look like this:

__LASTFOCUS=&__EVENTTARGET=&__EVENTARGUMENT=

However, by having the ENTER key cause the form post, the "cause" of the form post is manually set to actually be the button:

__LASTFOCUS=&__EVENTTARGET=Button_Search&__EVENTARGUMENT=undefined

This causes ASP.NET to have a fit if you do not have the following option set on the page (which can also be set through the web.config file):

<%@ Page EnableEventValidation="false"

The error you will see will be something like this:

Invalid postback or callback argument.  Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%@ Page EnableEventValidation="true" %> in a page.  For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them.  If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.

Care should be had when setting the EnableEventValidation to false as it is set to True for security reasons.

Source: http://msdn.microsoft.com/msdnmag/issues/07/06/silverlight/default.aspx

 

1.       Introduction.

a.       Currently supports Mac OSX Safari and FireFox, Windows FireFox and IE

b.      Can be interacted with by AJAX code.

2.       Introducing Silverlight

a.       XAML is text-based and exposes it’s DOM to the browser in a scriptable manner (therefore, it is “functional”).

b.      The browser loads the XAML and creates a DOM that can be interacted with via script code, including modifications by script and event handling/processing.  You may also interact with the XAML DOM through methods (such as methods that start playing, stop playing or pause a presentation).

3.       XAML Overview

a.       XAML was first introduced as part of Windows Presentation Foundation; though the XAML used by Silverlight is a web-based subset of the full XAML supported by WPF.

b.      Silverlight XAML markup is based on the <canvas> tag; the “surface” upon which objects will be drawn.

4.       Inside the XAML

a.       There is support for pre-defined shapes, gradients, etc.

5.        Transformations, Media, and Animations

a.       XAML has built in support for transformations on objects (MatrixTransform, RotationTransform, ScaleTransform, etc).

b.      MediaElement tag controls video and audio.

c.       Animations are defined in XAML by how properties change with time.

6.       A simple silverlight application

a.       Currently silverlight.js is required to be located within the /js folder for your web application.

b.      Sys.Silverlight.createObjectEx() implements a new silverlight control.

c.       The silverlight plugin loads into a DIV tag with a unique ID.

d.      Dynamic features can be added to the Silverlight application (such as the source for a particular video) but modifying the script that controls and instantiates the objects through the ASPX page’s rendered output.

7.       Delivering XAML to the Silverlight Front-End

a.       The server can process and build the XAML as needed; the Sys.Silverlight.createObjectEx() method simply takes this markup to load and instantiate the XAML as a silverlight object.           

For those that deal in the world of asynchronous clientside programming, you've definitely encoutered JSON - the JavaScript Object Notation. The standard way of taking JSON formatted data and transforming it back into the javascript objects which it describes has been the eval() method. The problem, though, is that this is effectively invoking the JavaScript parser engine for the browser on potentially untrusted code - the javascript parser will basically execute whatever you give it through this method.

A relatively nice article (http://msdn2.microsoft.com/en-us/library/bb299886.aspx), it describes a script library located off of www.json.org (http://www.json.org/json.js) that provides a much more secure way of parsing JSON formatted data "parseJSON()". It's cousin "toJSONString()" is used to create the JSON strings.

...personally I haven't used this methodology, but it appears promising (at least until there is a much more standardized way of doing it).  

I've heard this question several times in the past few months and the answer is - an astounding - not even close. In fact, I would say that ASP.NET AJAX is going to enjoy a long and fruitfull life as a development tool for ASP.NET developers over the next three to five years at least, probably even more (though it may morph into something else during that time). However, this question - as to whether all the new client-side visual tools like Silverlight - is the end of ASP.NET AJAX is a fairly decent one given that, still, not a whole lot of people fully understand the depth of ASP.NET AJAX. Let's take a brief look.

First, ASP.NET AJAX is not only about AJAX; it's a full, complete, end-to-end framework for developers who wish to (or are forced to) dive into advanced client-side scripting. Quite literally thousands of controls are floating around in the world today that require the use of JavasScript - and millions upon millions of websites are leveraging it for reasons of client-side richness and control. What ASP.NET AJAX gives to the JavaScript (ECMA Script) developer is as close to an object-oriented, .NET'ish programming platform as you can get - so the need to write platform agnostic logic is either completely removed or mostly removed. For the millions of developers in the world right now who use JavaScript in their controls and web applications, development tools like Silverlight will not help.

Second, Silverlight is - like Flash - more of a user-interface platform all in itself. Like Flash, it will require the download of necessary bits to the client machine, and once there, will require a compliant browser to operate within. You will be able to create compelling interfaces, no doubt, but it's focus is always going to be angled towards the designer; the guys who think in the world of "flash'yness" (pardon the expression). A highly effecient, intuitive intranet or CRM solution, on the other hand, will probably not be written, ever, in a development framework like Flash or Silverlight - the same goes for an eCommerce webstore or a highly dynamic news site. These more business-oriented solutions will benefit greatly from the nature and flexibility of markup within the browser; and therefore find great benefit in the asynchronous attributes offered through ASP.NET AJAX. It would certainly be interesting if all the web pages out there looked like a high-end Silverlight presentation, but realistically, that wouldn't be practical at all to developer or maintain.

Third, ASP.NET AJAX is undergoing great advancements through the community - which shows a high focus on it as an important aspect of ASP.NET development. The open source community is contributing a great amount to the control toolkit, and this shows no sign of stopping or even slowing down.

And finally, and most importantly, Silverlight, Flash or what-have-you is not (nor probably ever will be) a natural environment to build products and solutions in for the ASP.NET, data-driven website developer. We have been raised under the notion of markup and are trained with that in mind, our websites are built around it, and the end-user expects it; the idea of removing or lessening the effects of this trend would be insane.

So, in summary, I see Silverlight being good for things like this:

• Kiosks,
  
• Company main or "splash" pages,
• Games,
  
• Presentations

...the kinds of sites where a designer would be involved mostly. And I see ASP.NET AJAX coming into play with:

• Intranets,
  
• Customer Portals,
  
• eCommerce sites
• Highly database backed or data-driven sites (like www.live.com)

...the kinds of things where a developer would be involved mostly.

Basically, there is no way ASP.NET AJAX is dead or nearing death. End of story.