MarkItUp

Today I was calling a web service from an Ajax client in an application that I'm working on and I noticed that I wasn't getting any results.  To get a better idea of what was going on, I wired up the error handler for the web service call and did some tracing to see the error message.  The error handling code that I added looked like this:

var msg = String.format(
    "Stack trace: {0}\nService Error: {0}\nMessage: {1}\nStatus Code: {2}\nException Type: {3}\nTimed out: {4}",
    error.get_stackTrace(),
    error.get_message(),
    error.get_statusCode(),
    error.get_exceptionType(),
    error.get_timedOut()
    );

Sys.Debug.trace(msg);

I re-ran the application and this is the exception that was getting returned:

Stack trace:    at System.Web.Script.Serialization.JavaScriptSerializer.SerializeValueInternal...
Message: Specified cast is not valid.
Status Code: 500
Exception Type: System.InvalidCastException
Timed out: false

The exception was telling me that there was a serialization problem with the Type being returned from the web service call.  This was interesting to me because I had just changed the return Type of the ws method call.  I initially wondered whether there was some generated JS type that was cached and that the new Type that I was returning was different from it.  That seemed unlikely though so I looked at the members on the new Type that I was returning.  There was a Guid, an Int32, a custom Enum, and a string.  Hrmm.  I decided to remove the Enum property from the Type to see whether it was causing the failure, and sure enough, my application ran fine.  Here's the Enum that I was using:

public enum PinType : short {
    Standard = 0,
    Favourite = 1,
}

Next I added the enum based property back but I changed the enum so that it was a standard Int32-based one.  Again, it ran fine... so the problem is obviously that the built in JavaScriptSerializer cannot handle short's.  In my case I just decided to cut my losses and leave my enum inheriting from Int32, but here's an article that describes a bit about how to implement your own custom Json serializer to use with non-supported Types:

http://www.asp.net/ajax/documentation/live/mref/T_System_Web_Script_Serialization_JavaScriptConverter.aspx

When you have written your custom converter you can either add it programatically or via the web configuration file like so:

<jsonSerialization maxJsonLength="500">
    <converters>
        <add name="MyConverter"
            type="MarkItUp.CustomEnumTypeConverter"/>
    </converters>
</jsonSerialization>

I've been playing around with Virtual Earth a lot lately for a new, personal web application that I'm writing.  Writing this application has been a great learning experience as I'm using .NET 3.5 in VS2008 Beta 2, Virtual Earth, Silverlight, and plenty of ASP.NET Ajax goodness.  The application is a real client-centric beauty - actually there's only a Default.aspx page with a map on it at this stage, the rest is all driven in the client with async web service calls... the lot!

Working with the map has been an especially good experience, and it takes a bit to get into the new paradigm of navigating between locations on a map as opposed to navigating to different pages in a typical web site.

Anyways, today I added some effects that I thought worthy of blogging, so here goes... First, I added a context menu that appears when you right click on the map to display extra functions that the user can use.  Displaying a context menu is a simple matter of attaching to the onclilck event of the map:

this._map.AttachEvent("onclick", this.MapClickHandler);

In your handler function 'MapClickHandler' you can then check for the right button and display some UI for a context menu:

if( e.rightMouseButton ) {
    this._ContextMenu.Show(e.clientX, e.clientY, e.zoomLevel) ;
}

There's a good article here which shows how to do this, but you'll want to use the JavaScript that I've shown above instead of theirs, as mine works against the V5 version of the VirtualEarth API.  The article is good for showing a nice, simple context menu UI though, so go have a read of it.  The context menu ends up looking like this:

The next thing that I wanted to do was to add a little dot when you right click to display the context menu to better visualize the selection.  This is the same behavior as the little red dot that you see when you right click on the map at http://local.live.com/ - notice the little red dot at the top left corner of the context menu in the following image:

To achieve this effect, I inserted some code when handling the right mouse click to display a DIV with the appearance that I wanted:

if( e.rightMouseButton ) {
    this._DisplayDot(e.clientX, e.clientY) ;
    this._ContextMenu.Show(e.clientX, e.clientY, e.zoomLevel) ;
}else{
    this._HideDot() ;
    this._ContextMenu.Hide() ;
}

The _DisplayDot function looks like so:

_DisplayDot: function(clientX, clientY) {
    var dotselected = $get("dotselected") ;
    dotselected.style.display='block'; 
    dotselected.style.left = clientX - 5;
    dotselected.style.top = clientY - 5;

}

As you can see, it simply uses the $get function to get a hold of the DIV instance and then sets it to visible.  And Hiding it is just as simple...

_HideDot: function() {
    var dotselected = $get("dotselected") ;
    dotselected.style.display='none'; 
}

The next thing that I wanted to do was to ensure that the map zooms to where you right click when you choose Zoom from the context menu.  A lot of mapping apps don't do this, but it's definitely what I would class as expected behavior.  This is done by storing the co-ordinates when the ContextMenu is created like so:

if( e.rightMouseButton ) {
    this._DisplayDot(e.clientX, e.clientY) ;
    this._ContextMenu.Show(e.clientX, e.clientY, e.zoomLevel) ;
    var pixel = new VEPixel(e.mapX - 5, e.mapY - 5);
    this._selectedLL = this._map.PixelToLatLong(pixel);
}else{
    this._HideDot(e.clientX, e.clientY) ;
    this._ContextMenu.Hide() ;
    this._selectedLL = null ;
}

Doing this stores the LatLong so that it is available for any of the callback handlers for your context menu functions.  An example of how this might be used can be seen in this context menu function that I have for zooming to street level:

ZoomToCityLevel: function() {
    this._map.SetCenterAndZoom(this._selectedLL, 12);
    this._contextMenu.Hide() ;
    this._HideDot() ;
    this._selectedLL = null ;
}

When the user clicks on a custom context menu function I call this function which sets the map's zoom level to '12' and centers the map based on the stored co-ordinates that we collected when they right-clicked on the map.  This gives the desired effect of zooming to city level and scrolling the map to where the user selected - as opposed to simply zooming, which would zoom to the currently centered location, which might not have been anywhere near where the user clicked.

Anyways, a long post, but I hope that it helps someone, somewhere

I saw this via Duncan's blog this morning.  With Silverlight there are apparently two install modes.  You can either provide users with an inplace install experience whereby the Silverlight plug-inwill install while your users remain on the page whereas my understanding is that the alternative - an external install of the plug-in - will redirect your users to the Microsoft site to get the plug-in.  Click on the following link for more information:

Link to Web.Next : Silverlight Install Modes

Here's a link to the documentation for the new May 2007 Futures CTP release for asp.net:

ASP.NET AJAX Futures Release

The UpdatePanel is the nicest server control we've been given in a long while.  As someone who is a relative newcomer to ASP.NET Ajax programming you could be forgiven for thinking that it was some sort of voodoo magic.  The true beauty of the UpdatePanel lies in it's simplicity.  To use it, you wrap the controls that represent the part of the page that you want to get updated asynchronously within the UpdatePanel's ContentTemplate:

<asp:UpdatePanel ID="up1" runat="server" UpdateMode="conditional">
    <ContentTemplate>
        <asp:Label ID="lbl1" runat="server" />
        <asp:Button ID="btn1" runat="server" Text="Smack" OnClick="btn1_Click" />
    </ContentTemplate>
</asp:UpdatePanel>

When this UpdatePanel is embedded within a page, clicking the button will cause only that fragment of the page to be updated.  Now, as a seasoned ASP.NET developer you will know that there's no real magic here, but the question remains... how does all of that goodness happen? 

Underlying the UpdatePanel is a control called the PageRequestManager which carries out all of the out-of-band calls and the marshalling of HTML back onto the UI.  The PageRequestManager has 2 sides to it - there's an internal server-side component that is used as a sort of Strategy implementation by the ScriptManager for the async postback logic.  For example, the implementation of the AsyncPostBackSourceElementID property on the ScriptManager looks something like this:

public string AsyncPostBackSourceElementID {
    get {
        return this.PageRequestManager.AsyncPostBackSourceElementID;
    }
}

The other side of the PageRequestManager is a client-side component that is used to manage partial page updates and to control the lifecycle of a async postback request.  To better understand the PageRequestManager, consider the UpdateProgress control.  The UpdateProgress control can be used on a page to provide feedback to the user about when async callbacks are occurring.  These are typically used to display the little "Updating..." icons to the user while they await the update of an async callback operation resulting from their UpdatePanel posting back to the server.  The UpdateProgress control makes use of some of the client-side lifecycle events of the PageRequestManger to determine when the async request is beginning and when it is complete. 

There's an excellent article on the Ajax docs site which explains how to work with the events of the PageRequestManager:

Working with PageRequestManager Events

In this article I just want to show how you could use those lifecycle events to disable a button when they user clicks it and re-enable it when the async postback completes.  We'll use the UpdatePanel code listed above as the UI code for our scenario. 

We'll need to wire-up event handlers to the beginRequest event and the endRequest event so that we can write our disable/enable code.  We do that from within the Application's Load event like so:

function pageLoad() {
    with(Sys.WebForms.PageRequestManager.getInstance()) {
        add_beginRequest(beginRequestHandler);
        add_endRequest(endRequestHandler);
    }
}

From within our beginRequestHandler function we will receive an instance of the BeginRequestEventArgs class that we can use to determine the button that was clicked:

var _id = null ;

function beginRequestHandler(sender, args) {
    var e = args.get_postBackElement(); // e is an HTML DOM element
    _id = e.id ;
    SetControlEnabled(true) ;
}

function SetControlEnabled(enabled) {
    if(_id != null) {
        $get(_id).disabled = !enabled;
    }
}

Likewise, in our endRequestHandler we will receive an instance of the EndRequestEventArgs class, although we won't be able to use any of it's properties to determine the client element that was clicked - that's why we stored it in a field from within the beginRequestHandler.  So in the endRequestHandler we simply set the control to enabled:

function endRequestHandler(sender, args) {
    SetControlEnabled(false) ;
    _id = null ;
}

All that remains is to detach our event handlers in the Application's Unload event like so:

function pageUnload() {
    with(Sys.WebForms.PageRequestManager.getInstance()) {
        remove_beginRequest(beginRequestHandler);
        remove_endRequest(endRequestHandler);
    }
}

If you run that code you will see that the Button does indeed become disabled when you click on it until the partial page update is complete.

In looking through this code we've been able to see that there is a component called the PageRequestManager which lives on the client (and also on the server) and which creates a lifecycle of a partial page update.  We saw the beginRequest and endRequest events that are exposed by this control which would hopefully provide some understanding of the framework within which the UpdatePanel can operate.  Other significant things to know about events within the PageRequestManager's lifecycle are:

1. There is also an initializeRequest event that occurs before the beginRequest - just after the Sys.Net.WebRequest instance that will be associated with the callback has been created.
2. The EventArgs instances all contain an instance of the WebRequest instance
3. The EndRequestEventArgs contain information about whether any errors occurred so that you could implement custom client-side error notifications
4. The EndRequestEventArgs contain the raw JSON data that is posted back from the server

All of these provide us with valuable hooks within which to totally customize the user's experience throughout the partial update of an UpdatePanel.

As part of a broader series of posts about the ASP.NET 2.0 Web Part framework I've been playing with ASP.NET Ajax to learn more about how web parts and Ajax work together.  In this post I want to show off some of the new syntax that I've learned for working with client-side Javascript in ASP.Net Ajax, in particular the new syntax for working with DOM elements via classes in the Sys.UI Namespace. 

Sys.UI is a compatability layer for working with DOM elements via an API that abstracts the developer from the vagaries of the different browsers.  The main 2 types in the Sys.UI namespace are DomElement and DomEvent classes.  DomElement is a class which defines a common set of methods and properties for working with DOM elements and likewise, the DomEvent class provides a consistent, cross-browser API for when working with events in the DOM.

Let's start by taking one of the static methods from the Sys.UI.DomElement to see how this works.  Without the use of the ASP.NET Ajax Client Framework we can write code such as this to get a handle to a DOM element from within a page:

var el = document.getElementById("elementID") ;

This will work in all modern browsers such as IE, Firefox, and Safari but might for browsers that don't support the getElementById function - such as pre-IE5 vintage browsers - then getting a specific DOM element would mean walking the DOM tree.  The DomElement class provides a simple method for performing this function which abstracts away from the developer the need to check which browser is being used.  The following syntax shows how to get a handle to a DOM element using ASP.NET Ajax:

var el = Sys.UI.DomElement.getElementById("elementID") ;

Even easier is the fact that the ASP.NET Ajax Client Library provides a shortcut for performing this action by using a global shortcut reference to the Sys.UI.DomElement.getElementById function - $get.  The following syntax is 100% equivalent to the previous snippet of code:

var el = $get("elementID") ;

Similarly, when working with events we can use static helper methods on the Sys.UI.DomEvent class to attach and remove event handlers to events within the DOM.  Using these shortcuts again shields us from the myriad ways that this is done across the range of browsers that exist.  The following snippet of code is for a sample page which shows how to attach and remove an event handling function to a DOM event:

var e = null ;

function pageLoad() {
    e = $get("foo") ;
    $addHandler(e, "mouseover", mouseoverHandler) ;
    $addHandler(e, "mouseout", mouseoutHandler) ;
}

function pageUnload() {
    $removeHandler(e, "mouseover", mouseoverHandler) ;
    $removeHandler(e, "mouseout", mouseoutHandler) ;
    e = null ;
}

function mouseoverHandler(evt) {
    Sys.UI.DomElement.removeCssClass(e, "normal") ;
    Sys.UI.DomElement.addCssClass(e, "hover") ;
}

function mouseoutHandler(evt) {
    Sys.UI.DomElement.removeCssClass(e, "hover") ;
    Sys.UI.DomElement.addCssClass(e, "normal") ;
}

NOTE: Don't forget that for this page to run you must include an asp:ScriptManager control in your page!

In the code we can see that we use the shortcut syntax of pageLoad to handle the load event on the Sys.Application where we then use the $get syntax to get a handle to a DIV element in our page with the ID of "foo".  Once we have a handle to that element we then use the $addHandler syntax - which is another global shortcut method for the Sys.UI.DomEvent.addHandler function - to attach event handlers to the mouseover and mouseout events of our DomElement.  In our handler functions we set the CSS class on our element by using more Sys.UI.DomElement helper functions - removeCssClass and addCssClass.  Finally, in the pageUnload event we clean up our references so that we don't cause memory leaks.

So that's a nice demo for highlighting several of the new client-side programming functions and events and shows how simple it is to perform such a common function as toggling the color of a link when the user hovers over it - who could ever remember that pesky syntax for setting the CSS class on elements for cross browser compatability anyway eh?

Rather than holding that global reference to the "e" variable just so that I can use it in each of the other functions I'm going to remove it and get the reference with the functions when I need it.  While performing this refactoring I'm going to make use of the target property of the Sys.UI.DomEvent class that gets passed to our event handling functions.  I'll also make use of the toggleCssClass function to remove another couple of redundant lines of code too:

function pageLoad() {
    var e = $get("foo");
    Sys.UI.DomElement.addCssClass(e, "normal") ; ;
    $addHandler(e, "mouseover", mouseoverHandler) ;
    $addHandler(e, "mouseout", mouseoutHandler) ;
}

function pageUnload() {
    var e = $get("foo");
    $removeHandler(e, "mouseover", mouseoverHandler) ;
    $removeHandler(e, "mouseout", mouseoutHandler) ;
}

function mouseoverHandler(evt) {
    Sys.UI.DomElement.toggleCssClass(evt.target, "hover") ;
}

function mouseoutHandler(evt) {
    Sys.UI.DomElement.toggleCssClass(evt.target, "hover") ;
}

There's another nice refactoring that we can make to this code by using two more helper functions - $addHandlers and $clearHandlers.  These global helper functions map to the Sys.UI.DomEvent.addHandlers and Sys.UI.DomEvent.clearHandlers functions as you would expect, but we are again given this nice shortcut syntax for working with them.  Here is the last snippet of code for our page with our final refactorings in place:

function pageLoad() {
    $addHandlers($get("foo"), {"mouseover":mouseoverHandler, "mouseout":mouseoutHandler}, this)
}

function pageUnload() {
    $clearHandlers($get("foo"))
}

function mouseoverHandler(evt) {
    Sys.UI.DomElement.toggleCssClass(evt.target, "hover") ;
}

function mouseoutHandler(evt) {
    Sys.UI.DomElement.toggleCssClass(evt.target, "hover") ;
}

So that's it.  A long but decent introductory article to working with DomElements and DomEvents with the ASP.NET Ajax client library.  As I said at the beginning of this article, Sys.UI is really a compatability layer for working with the DOM.  I'd really encourage taking a look at the other major sections of the client library to see what other functionality exists:

ASP.NET Ajax - Client Reference

In particular I'd encourage looking into the Sys namespace where you can find classes like the StringBuilder, Debug, and Exceptions.  In addition to that, if you needed any more convincing that this is not your grandfather's JavaScript, take a look at the JavaScript Base Type Exceptions in the Global namespace to see which existing JS types have been extended.  For example with a little spelunking around there you will find some familiar favourites such as String.format:

var obj = {foo:"foo", bar:"bar"} ;
alert(String.format("Foo: {0}, Bar: {1}", obj.foo, obj.bar)) ;

Go for it!

 Nikhil has just posted an update to his UpdateControls:

UpdateControls 1.1: Bug Fixes and UpdateAction

Included in this update is a new control called the UpdateAction control which provides a slot for the programmer to have structured access to page controls during a partial postback.  Combined with other controls in Nikhil's UpdateControls, such as the AnimatedUpdatePanel, this is creating an even richer framework for implementing common Ajax patterns.

In this post Bertrand discusses the various techniques for wiring up event handlers in client-side OO code and the slight but important differences between them:

Link to Atlas and more : How to keep some context attached to a JavaScript event handler?

I'd highly recommend cracking open VS and playing around with these to get a good feel for the differences.

Recently on an ASP.NET list there was some discussion about this article:

Link to AJAX Apps Ripe Targets for JavaScript Hijacking

In the article - dated April 2, 2007 - it is mentioned that ASP.NET Ajax, along with several other leading AJAX implementations - such as the Google Web Toolkit - has a JavaScript-related security vulnerability.  This article was based on a blog post written by Brian Chess, co-founder and "Chief Scientist" of a company named Fortify Software.

2 days after that article was released, Scott Guthrie posted his own blog article which states that ASP.NET Ajax is not vulnerable to this threat:

http://weblogs.asp.net/scottgu/archive/2007/04/04/json-hijacking-and-how-asp-net-ajax-1-0-mitigates-these-attacks.aspx

It's all interesting reading and makes you thankful to be building atop tested, patchable frameworks such as ASP.NET

So many things were improved in ASP.NET 2.0!  Today I was reminded of some of these improvements and so I wanted to make a bit of a blog "Note to Self" about what they were.

Remember what it was like when you created custom server controls in ASP.NET 1.x?  It was cool, and you could do it, but there were many things that caused pain.  I created lots of custom controls in the 1.x days and packaged many of them for use by external users, so I got a pretty good feel for the "pain points".  This weekend was the first time that I really sat down with the aim of creating a custom server control in ASP.NET 2.0 that I was hoping to package for external users and some of the changes surprised me.

Resources

The first notable improvement was in how resources are handled.  In 1.x you would typically either add resources as embedded resources or, as I saw on many occassions - including with ASP.NET itself - package resources as external files to be copied to the filesystem.  If you took the embedded resources path, here's the type of code that you had to write to extract your scripts and embed them in the page with your control:

Type t = typeof(timer) ;
Assembly ass = t.Assembly ;

using (StreamReader reader = new StreamReader(ass.GetManifestResourceStream(t, "TimerScript.js"))) {

    string script = "<script language='javascript' type='text/javascript' >" + reader.ReadToEnd() + "</script>" ;
    this.Page.RegisterClientScriptBlock(scriptKey, script);
}

There's some tricky, low-level code there - and it get's much more difficult if you want to maximise caching and stuff.  In ASP.NET 2.0 there's a much more "typed" version of how to embed resources.  Nikhil has a couple of great articles which describe how this works:

WebResourceAttribute

Web Resouces - Design Time

Essentially, to embed a JavaScript in a custom control in ASP.NET 2.0 you would do the following:

1. Add your JavaScript file to your Custom Control library and set it's build action as "Embedded Resource"
2. Add a WebResource assembly attribute to your assembly to mark your resource as web accessible:
   
       [assembly: WebResource("Button.gif", ContentType.ImageGif)]
   
3. If your resource is an image, you can now simply reference that image like so:
   
       myButton.ImageUrl = Page.GetWebResourceUrl(typeof(MyCustomControl), "Button.gif");

Nikhil's articles explain all of the other details that you need to know about WebResourceAttribute and how it works.

Client Scripts

Even before tMicrosoft Ajax, ASP.NET 2.0 added new support for working with client scripts as a control author.  Most importantly, they moved the script logic from the Page, ie:

Page.RegisterStartupScript(...) ;

to a new ClientScriptManager class:

Page.ScriptManager.RegisterStartupScript(...);

where ScriptManager represents an instance of the ClientScriptManager class.  One of the interesting things about the ClientScriptManager class is that many of it's methods require a "Type" argument to be passed in.  Here's an example of using the Type argument in the RegisterStartupScript method:

scripts.RegisterClientScriptResource(typeof(PageLoad), "MarkItUp.WebControls.PageLoadScripts.js");

Note that, for the first argument I pass in the type of my custom control class (PageLoad).  This argument is used as a key for determining the scope of the resource that will be emitted.  Here's a nice article by Rick Strahl which talks about the Type argument and discusses some gotchas with it:

http://west-wind.com/WebLog/posts/9837.aspx

 

Script Control

With the advent of Ajax, ASP.NET has included much more support for working with scripts and client-side object from within server-side code.  I'd actually forgotten about some of this stuff until today when Glav tidied up some of my "old school" custom control code and replaced it with the shiny new stuff.  Here's an overview of the changes that he made. 

First, he changed my control so that, instead of inheriting from WebControl, it instead inherited from ScriptControl.  This control implements the IScriptControl interface which means that it contains two important methods for control authors: GetScriptDescriptors, and GetScriptReferences.

GetScriptReferences

...allows you to return a collection of each script reference that you wish emit with your control.  The syntax is really simple:

protected override IEnumerable<ScriptReference> GetScriptReferences() {
    ScriptReference script = new ScriptReference("YourNamespace.YourJavascriptFile.js", "Your.Assembly");
    yield return script;
}

GetScriptDescriptors

...is a very useful method which removes a lot of the fiddly and potentially buggy (and non-typed) code that control authors used to use to instantiate client side instances of their control and to set its properties.  There are ScriptComponentDescriptors - for working with Ajax component client types - and ScriptBehaviourDescriptors - for working with Ajax behaviour client types.  Under the hood, ScriptDescriptors map to the Ajax client $create method which is used to instantiate client types at runtime, but this provides a very type-safe and clean way of working with these client-side statements.

As a refresher, this is what the client-side $create Ajax method looks like:

$create(type, properties, events, references, element);

The ASP.NET syntax for creating Ajax types from the server is to use ScriptDescriptors.  To create a type instance, simply create an instance of a descriptor and return it from the GetScriptDescriptors method of your ScriptControl:

protected override IEnumerable<ScriptDescriptor> GetScriptDescriptors() {
    ScriptComponentDescriptor cmp = new ScriptComponentDescriptor("MyNamespace.MyClass");
    yield return cmp;
}

To fill in other arguments in the $create statement, you can use the AddProperty, AddEvent, and AddComponentProperty methods to fill those in.  In the example where you want to instantiate a client type named Samples.SimpleComponent and construct that type by setting it's AProp property to 5000, you can use the AddProperty method to fill in that constructor information like so:

protected override IEnumerable<ScriptDescriptor> GetScriptDescriptors() {
    ScriptComponentDescriptor cmp = new ScriptComponentDescriptor("Samples.SimpleComponent");
    cmp.AddProperty("AProp", 5000);
    cmp.AddProperty("id", this.ID) ;
    yield return cmp;
}

You can see what the Javascript code for the Samples.SimpleComponent looks like here:

http://ajax.asp.net/docs/tutorials/CreatingClientComponentPrototype.aspx

Rocky was a pretty paranoid guy and I'm not quite sure what he'd think about cool new technologies like Ajax.  Me: I see them as a great new way to build engaging UI's by providing more responsive web applications.  Rocky: he'd be likely to just see them as a new attack surface or something.  Poor Rocky.

Anyway, some of working with Rock must have rubbed off on me because now I find that I'm acting more responsibly by doing things like locking my keyboard when I leave my desk and checking my inputs when I code.  To that end I watched this great webcast (not sure what happened in the first 5 minutes... just forward past that part) about the next generation of attacks centered on Ajax:

The Next Generation of AJAX Attacks – A New Generation of Attack Theories event

The webcast highlights some key areas to think about that are made more prevalent through the use of Ajax - such as attackers using the Bridges that are used in Mash-ups to deliver attacks from behind the safety of another web application - and what the implications of this are.  There's also a lot of the usual common sense stuff like checking input parameters.  The good thing is that these guys talk about those topics in a very relevant way.  For example, for data being passed around it's not just rendering of that data to the UI that can expose you to nasties - like cross-site scripting attacks - but there are many times in JavaScript where strings and objects are dynamically executed - examples include setTimeout, setInterval, eval, and dynamic html writing which all allow for malicious use of strings.

Well that's it from me... just gunna head off an check my buffers for overflows!

DotNetSlackers are running a competition to give away an MSDN Premium Subscription for whomever submits the coolest Atlas Control/Extender.  Can't wait to see the entries that come in for that!

One of the Live.com guys has posted a lengthy article about their key learnings from building Live.com:

    http://spaces.msn.com/siteexperts/blog/cns!CE6C50D25BFAAA73!4852.entry

This is interesting in that it is the first decent attempt that I have seen to do a post mortem on an AJAX implementation to identify and discuss some of the issues. A must read for any would be AJAX developers.

I was fortunate enough to see a preview of the Live.com platform last night in Sydney.  At the event I saw the Live applications and heard about the future of the platform.  I have to say that I walked away with a head full of ideas.

My main interest in Live.com centers around gadgets and so I'm very interested to see whether  "Live" exposes an open set of services that could act as a bedrock for building rich Web 2.0 mash-up style applications.  My hope is that at some point developers will be able to tap in to the Live services to create gadgets that are highly personalized and which target the end-user.

I haven't done a lot of research into gadgets at this stage but I'm very keen to learn more about where Microsoft is heading with this stuff.   If the Live services are open then this is going to be an amazing time to be a component builder in the web apps space.

If, like me you've been trying to keep abreast of the moving target which is "Atlas" you'll be excited to know that Nikhil has posted a bunch of recent samples that run against the Dec CTP of Atlas.  You can grab the details here:

    http://www.nikhilk.net/Entry.aspx?id=104

Highly recommended!