rickgaribay.net

Space shuttles aren't built for rocket scientists, they're built for astronauts. The goal isn't the ship, its the moon.
posts - 303, comments - 180, trackbacks - 35

My Links

News

Where's Rick?


AgileAlliance deliver:Agile 2019- 4/29
Desert Code Camp, PHX - 10/11
VS Live Austin, TX - 6/3
VS Live SF - 6/17


About Me
Hands on leader, developer, architect specializing in the design and delivery of distributed systems in lean, agile environments with an emphasis in continuous improvement across people, process and technology. Speaker and published author with 18 years' experience leading the delivery of large and/or complex, high-impact distributed solutions in Retail, Intelligent Transportation, and Gaming & Hospitality.

I'm currently a Principal Engineer at Amazon, within the North America Consumer organization leading our global listings strategy that enable bulk and non-bulk listing experiences for our WW Selling Partners via apps, devices and APIs.

Full bio

Note: All postings on this site are my own and don’t necessarily represent the views of my employer.



Check out my publications on Amazon Kindle!





Archives

Post Categories

Published Works

HTML DOM "Interop" With Silverlight

With the announcement of Silverlight 1.1 on April 30th, the big news in my world is all about the CLR in the browser. In a previous post I talked about what a watershed moment this integration represents for web development in general. I have to emphasise that the ability to render eye-candy graphics is not the root of my excitement. It is the ability to truly deliver RIAs on the browser with .NET, period.

One of my almost immediate follow up questions was how vanilla HTML would work. You know, the equivelent of flipping the "ugly" switch. The ability to write plain 'ol HTML is important because I don't think the average developer is going to be any good at designing Silverlight UIs. I know I won't. I mean, my buttons might be Silverlight and I might have some cool transforms, but unless I get some good assets to play with, my apps will be ugly unless I invest some real time in learning some design skills. The latter is unlikely because my focus is in other areas of application development.

It turns out that there is a bridge between the CLR and the DOM, and it is via the System.Windows.Browser namespace. The HtmlPage class represents the entry point into the DOM and exposes various properties and methods for interacting with the browser. On the surface, this sounds strange, doesn't it? The idea of interop between Silverlight and the browser. But it makes sense, the CLR is a self contained runtime that has no direct communication link with the browser. I imagine that this namespace will become more and more sophisticated as it plays the key role of bridge between the CLR and the browser. Mike Ormond has a good brain dump on one of the Silverlight programability sessions which is quite accurate: http://blogs.msdn.com/mikeormond/archive/2007/05/01/net-for-silverlight-some-features.aspx

What about networking? This is an interesting topic because as much of a step forward that putting the CLR into the browser is (revolutionary, really), I can't help but feel that we have taken a couple of steps back. For example, ASMX/WCF plumbing isn't quite there yet (but will be I'm told) so instead the option is to resort to XML HTTP POST semantics or, as an interesting trick, use JSON serialization to do WS-BASIC Profile I Web services. I thought we had moved beyond JSON years ago, but it does work. All of this is handled in the System.Windows.Browser.Net namespace. The ability to do both synchronous and asynchronous calls to the cloud are fully supported and this is HUGE since the HTTP protocol all but precluded callbacks on an ASP.NET application unless you wanted to do XMLHTTP or AJAX.

Also of interest is the fact that LINQ is fully supported which I see as positive, but it could also encorage bad habits. I don't want to see LINQ code in UI, but there is nothing to say that we can't put a UI Process layer in Silverlight. This is a common layer in architecting ASP.NET apps that do a lot of databinding, paging, etc. The idea is that a lot of this code is re-usable, so put it in its own class and have the UI use it as helper methods. This is the right approach IMO, but I am sure we will see direct LINQ manips right in the XAML code-behind but that is what code reviews are for, right?

 

Print | posted on Wednesday, May 02, 2007 7:15 AM | Filed Under [ Misc. ]

Feedback

Gravatar

# re: HTML DOM "Interop" With Silverlight

Much agreed. I have started to implement that practice. I've also started to use Script tags to store this kind of information as well.
12/15/2009 4:33 AM | jeu du keno
Comments have been closed on this topic.

Powered by: