Rants Tagged with “Silverlight 2”
When I teach Silverlight 2, I stress an important lesson that I thought that we (as developers) had learned the importance of linkability of the web. Early usage of Flash was the first time I noticed this. A number of those sites would create nested functionality that never changed the URL. If the URL doesn't change, i can't bookmark it. Most Flash guys learned their lessons pretty quick, but now I am inundated with AJAX driven sites that try hard to not to do post-backs. That's cool, but if the URL doesn't change I can't link to it.
I've noticed this happening a lot with support sites. The first time I saw with an AJAX site was using the Intersoft's Developer Portal (http://www.intersoftpt.com). They treat the developer to a desktop-like experience, but if I can't send a link to my other developers for the latest patch, why bother making it on the web?
The latest is the game Spore's forums. Trying to help a friend figure out why its crashing, I found some good posts on workarounds but the site's address is always http://www.spore.com/forum. What's the point?
This post is a request...a pleading...begging even. Think about the usability of your sites. If it lives on the Internet, it should be linkable. Now if your site doesn't have state, this doesn't apply to you, but for the other 99.999% of the sites out there, don't get too caught up in the frenzy of AJAX or RIA to make your sites usable. The reality is that you can do this with Silverlight, Flash, AJAX or any web page. It might be more work, but the level of frustration for users is well worth your time.
(NOTE: Microsoft is working on a new version of their AJAX toolkit to enable URL changes during partial page updates. This will help some of you, but the rest of you will still need to do some of the hard work yourselves.)
If you've used Silverlight 2 much, you probably have already run into the issue with URI's that can be specified in XAML (e.g. Image and MediaElement). When using relative URI's for these elements, Silverlight 2 uses a "Site of Origin" resolution symantic. Instead of resolving the relative URI's based on the website that the Silverlight 2 application is hosted on, it resolves it based on the site of the origin of the application (the .xap file). If the application is hosted on a site (i.e. http://mysite.com) and our .xap file is in a directory (i.e. http://mysite.com/ClientBin), then a relative URI will be resolved based on the locaiton of the .xap file. This means that a relative URI like "/foo.jpg" we resolve to "http://mysite.com/ClientBin/foo.jpg" *not* "http://mysite.com/foo.jpg" as you might expect. In fact, changing this to "../foo.jpg" doesn't change anything. It thinks that the directory of the .xap file is the root of the URI, no matter what you do. Lastly, this also means that if your .xap file is hosted on a site other than your website, these URI's are relatvie to that remote web server, not yours.
These URI's are special because relative URI's look in the .xap file itself first. That's why you can include images in the .xap file and use them with relative URI's in Silverlight 2 without having to have a special syntax to specify the xap file itself. In addition, this syntax is meant to avoid having to learn the cryptic pack:// URI syntax that is used in WPF to retrieve items. So what can we do to simply this?
My initial approach was to try and make a XAML markup extension or something else nearly as arcane, but now I have a simple approach. I have started to place my .xap files at the the root of my web applications. This is in stark contrast to what the tools suggest (e.g. using a ClientBin directory), this means that these relative URI's will act like the root webserver. So far I have not found a drawback to this approach.
To do this you will change the directory from ClientBin to simply blank. For example, when you view the silverlight applicaitons (in the website properties), you can use the "Add" button to link a Silverlight application to your website:
When you add the Silverlight application, make sure and clear the Destination folder:
This will place the .xap files in the root of the web site and therefore relative URI's will resolve just like every other relative URI. Voila!
If you know of a good reason not to do this, please comment below. I am vetting the technique to make sure its a good piece of advice to give.
This week, I will be joining Glen Gordon and Chad Brooks for a GeekSpeak webcast. The Webcast starts at 3pm EST (or noon PST) on Wednesday, June 25th, 2008. We will be discussing Silverlight 2 and its use in so called "Line of Business" applications. Please join us and bring your questions.
If you don't know what a GeekSpeak event is, here is a description straight from Microsoft's website:
MSDN geekSpeak is a fresh kind of webcast series, hosted by Glen Gordon and Lynn Langit of the MSDN Events team. Dispensing with traditional slide decks and scripted demos, geekSpeak brings you industry experts in a talk-radio format. These experts share their knowledge and experience around a particular developer technology.
See you there!
We had a geek dinner tonight in Washington, DC. I can't thank G. Andrew Duthie enough for facilitating the whole night. We got to discuss Silverlight, .NET, Origami, iPhone, Zunes, and everything great in technology. It was a great time to see everyone. Thanks again for a good time.
Silverlight.net has announced a new Community Recognition program!. They've instituted a new point system to recognize community contributions to the site.
I am humbled that I made their Hall of Fame:
http://silverlight.net/community/recognition/hall-of-fame/
Bill Reiss is at it again. He's converted his Dr. Popper game to the Silverlight 2 Beta 2 bits and has released the source code (you can find it here). The source code is different from the version of the game on his site as that version allows users to compete by storing high scores on his server. If you want to compete for the high score, view the one on his site at:
http://www.bluerosegames.com/brg/games.aspx
In the documentation and change documents in Silverlight 2 Beta 2, they mention that the format of the Deep Zoom files have changed from a binary to an XML file. In fact, then mention that the file is called .DZI for a single image, and .DZC for an image collection.
Unfortunatley the DeepZoom Composer people didn't get the story. When they create the images for you, they create DZI_OUTPUT.XML or DZC_OUTPUT.XML as the file that you should be pointing at. You can manually change these to .dzi or .dzc if you like (I would as I expect this is just a bug).
You can test this by creating a Silverlight Wrapper from DeepZoom Composer when you output your files and see that the URI they are specifying is the *_OUTPUT.XML file.
HTH
I want to thank Erik Mork for talking with me on his Sparkling Client PodCast. We talk about Silverlight 2 Beta 2, some caveats about upgrading and where I think Silverlight 2 is headed. Its a short, fun talk.
Don't forget to subscribe if you like the content as this PodCast is exclusively Silverlight talk....
I am headed to Europe this fall for two .NET conferences on the continent. I am excited to be speaking at these two great conferences:
First up is the SDN Conference 2008 in Amsterdam, The Netherlands on October 6-7th, 2008. I will be speaking on Silverlight 2 Control Customization, Visual State Manager and ADO.NET Data Services. I am excited to see my old adopted home again! Et Lekker!
Second up is
DevReach in Sofia, Bulgaria on October 13-15th, 2008. The schedule hasn't been finalized so I am not sure yet what I'll be speaking on but you can probably guess the usual Silverlight,
ADO.NET Data Services,
Entity Framework or
DSL stuff I am interested in.
If you're in either of these locations this fall, look me up!
My recent post on upgrading your Silverlight 2 Beta 2 projects has fairly brief as I expected the blogosphere to be full of blog posts on it. Unfortunately, there hasn't been a lot of posts so I decided to expand the blog post to deal with most of the big issues. If you're upgrading, take a look at this more lengthy version of the post.
