Rants Tagged with “Silverlight 2”
We are pleased to announce that Wildermuth Consulting Services has partnered with RunAtServer Consulting of Montréal, Canada to translate our course into French. They will be giving the course in Montréal and Québec City:
- Montréal - September 5-7th, 2008
- Québec City - November 5-7th, 2008
- Montréal - November 19-21st, 2008
- Montréal - January 26-28th, 2009
If you've been waiting for a French version of the workshop, your time has come!
In this TechCrunch article, they report that Adobe has released a stripped down version of the engine that can parse the swf files and give back info that is useful for the indexing engines. Its unknown whether Google or Yahoo (the report doesn't mention Live.com as one of the search engines it gave the technology to) will use it, but I expect they will.
So the question comes up, what about Silverlight apps? Will SEO for Silverlight become a big bargaining chip? I hope Microsoft responds though with the .xap and XAML files, Silverlight is already pretty easy to consume. My one request would be that Silverlight 2 stop embedding the .xaml into the assemblies so that the search engines don't have to double dig to get to the XAML.
Now that Silverlight 2 is getting closer to a reality (and a Go-Live license) the 3rd party controls are starting to sneak out. None of these are in 'release' quality but I thought it might help to get my opinion on the current state of these controls. Some of the vendors are releasing previews of their entire Silverlight 2 suites while others are releasing teaser controls (and some are even free!).
Caveat: I don't think its fair to 'review' these suites, I have included some comments about what I like and don't like about the controls. Please don't take any of these comments as a 'review'.
In testing these, I simple was creating them ad-hoc with XAML. I did not test them with Blend at all. Here are the controls I've looked at so far (in no particular order):
ComponentOne Studio for Silverlight (M2 Preview Release):
This control suite looks like the most complete of the bunch. While I don't prefer the speed of the Tree control or the look/feel of the DataGrid, overall its a great set of tools. I particular like the input controls (e.g. MaskedEdit) and the Image Rotator. It comes with lots of examples and seems to abide by design standards pretty well. My biggest complaint is the sheer size of the library. The shared part of the library is over 500K and on top of that you layer one of a number of assembllies that contain the controls. This means that a typical app is bloated by about 200-400K (after xap compression).
DevExpress's AgDataGrid (Beta 1):
Another data grid that's been thrown into the mix, DevExpress's grid seems to perform pretty well though it is buggy with some of its implementation of ObservableColleciton...but it is Beta, right? Out of the box the Microsoft grid seems to do more than this grid but with a quick look under the covers its obvious that this is a powerful control. My only peeve is that they seem to be modeling this off their WinForms grid in its naming of common properties (e.g. DataSource instead of ItemsSource). But that's not a big complaint.
Telerik's RadControls for Silverlight 2:
I am less than blown away with these controls. This suite doesn't quite seem to know what it wants to be with a mix of different types of controls thrown together (rotating cube, video player, tree control, and uploader et al.) it seems like mix of single use controls instead of a suite for a specific market (i.e. ComponentOne seems directly aimed at Line of Business apps). For the most part the controls work as advertised but they don't behave well for measurement and arrangement (which means they are wonky in a Grid). This is the only suite that doesn't mark itself as a non-released version (there was no indication of Beta, CTP, Alpha, etc.) so I suspect its a very early cobbling of some of their controls to give us a preview of what they're capable of. In addition, there is no segmentation of their controls so you're required to use the entire 900K+ assembly even if you only need one of their controls.
Infragistics NetAdvantage for Silverlight CTP:
I used the UltraGauge and UltraChart to create a simple example using live data and was pleasantly surprised. The UltraChart was powerful and worked much like expected. The range of customization seemed deep and performance was good. The docs are a little lacking but at this point in their development they are what I would expect. The UltraGauge I was less happy with as it took a substantial amount of XAML to achieve even a simple radial gauge and setting values is not simple. This complexity is probably a benefit for customers looking for a very flexible Gauge, but for simple work it is a lot of work to get simple stuff to work.
Visifire Silverlight Charts:
The licensing (open source/free) is great. For straightforward charting, its a great solution. Two things that make me less than thrilled with it though: height/width must be specified (breaking design standards and annoying users); and will not dynamically display chart information. Adding data to the chart's series' simple does nothing. No redisplay no matter what I tried. The examples the site uses to show dynamic data involve updating external data and restarting the Silverlight application. Too bad too...
Netika Tech's GOA for Silverlight:
I decided not to review the GOA for Silverlight project as its really an implementation of Windows Forms for Silverlight and isn't really a control suite but a porting package.
Tim Heuer again to the rescue. I had started a Dynamic .xap file demo to figure out how all that dynamic .xap stuff worked when he released a new video detailing it exceptionally. Run over to Method ~ of ~ failed and see the other videos he has for you...
I've been digging into some of the open source and 3rd party controls that are becoming available for Silverlight 2. While running into some odd issues with some of them it occurred to me that there are some design guidelines that haven't been well communicated. Back in the early days of WPF I learned (though exactly where is unclear) that every control should support an empty constructor and that all properties (e.g. XAML Attributes) should have a default value. I knew this to be true but I couldn't document where it came from.
So as usual when I am stuck, I contacted Chris Sells as he was my mentor in early XAML usage. He was at MSDN at the time gathering content and helped me get the Data Binding articles as well into the Software Design Review for WPF (then Avalon). If anyone could help me figure out where I learned this, he'd know. He reminded me of the language they use internally: "Create-Set-Use". Essentially this means that the design pattern for controls is that they should work without requiring any properties:
<Grid ...>
<Rectangle />
</Grid>
You can see that the Rectangle doesn't require any properties to be valid. Of course this Rectangle has no fill brush and no stroke brush which means it will likely not be visible. But that's OK because it is valid XAML and doesn't break. The XAML for a control doesn't have to read the mind of the user, but should behave (e.g. not throw exceptions). One of the most egregious was a control that threw an exception if I failed to set the Width and Height. Worse yet, when it did throw these exceptions, it didn't tell me what *all* the properties I needed therefore it was painful to use. Width and Height are particularly problematic in this way in that by not defaulting to "Auto", showing the control in a non-Canvas container meant I needed to set "Auto" to the values which is what they should *always* be defaulted to.
Create-Set-Use happens during parsing of the XAML. This comes back to thinking of XAML as a serialization format for in-memory objects. XAML is simply a way to define what the structure of a particular document should be when its de-serialized. If you keep in mind that an Element becomes an object construction and that properties become SetValue calls, it makes it fairly clear what is happening during the parsing of the XAML itself.
As you write your own Silverlight or WPF classes that you expect to be used in XAML (this includes controls but also may be types that can be created as resources), try to keep these design ideas in mind. It will make life easier for your users.
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/
