For large hierarchies the TreeView in the Silverlight tool-kit suffers some performance problems, because the elements (once loaded and expanded, such that they could be seen by the user if they scrolled the scroll-bar) aren’t virtualized as aggressively as they could be. The for example the hierarchy shown below: If Child Node 4 is expanded, pushing Child Node 5 outside the limits of the view port of the TreeView then Node 5, as well as any other children of Node 4 that aren’t directly visible, _could_ be virtualized but currently aren’t by the Silverlight Treeview. When the number of invisible-but-loaded nodes is small the performance impact is negligible, but if Node 4 (in the example below) had 10,000 children, each with a complex data template applied to them the performance impact expanding the tree can be quite noticeable.
One approach to get around this is to recognize that a TreeView is just a List with indentation and expand/collapse semantics. By flattening your object hierarchy with an appropriate wrapper you can use the virtualization that is built into the ListBox, which happily does virtualize items that have disappeared off the top or the bottom of the list, by virtue of its use of the VirtualizingStackPanel that was added in Silverlight 3.
The sample provided does just that with two classes TreeViewModel<T> and NodeViewModel<T>. TreeViewModel<T> contains a Nodes collection, an ObservableCollection of NodeViewModel<T> which the list is bound to. The visibility of the expand/collapse arrow is bound to the presence of children. When a NodeViewModel<T> is expanded it calls back to the TreeViewModel<T> to tell the TreeViewModel to create a new set of NodeViewModels based on the children of the node being expanded, and to insert them directly after node being expanded in the current list of nodes. When the TreeViewModel makes new nodes it increments the indentation property, which is used to drive how far in the node is rendered when it is shown. When a NodeViewModel<T> is collapsed it again calls the TreeViewModel<T> and basically tells it to throw away all the nodes that come after me in the Nodes collection, until you reach one that has the same indentation as me (or you reach the end of the list), at which point the TreeViewModel will know that it has removed all the children of the item that was collapsed.
The sample provided is not a complete drop-in replacement for the TreeView control in the Silverlight toolkit. For one thing some of the expand/collapse semantics are a little different to a standard TreeView. For example if all the nodes in the tree are fully expanded, and the root node is collapsed and then re-expanded then the standard tree-view behaviour is for the tree to look the same as before the root node was collapsed, however this tree will only show the direct children of the root node after the root node is collapsed and then re-expanded, regardless of the state of the tree before. This is a side-effect of the way this implementation creates and destroys NodeViewModel<T> instances when a node is collapsed/expanded. When a NodeViewModel<T> is removed from the list of nodes the fact that it was previously expanded is lost. This could be changed by keeping instances of removed nodes around, but would complicate the expand/collapse methods in TreeViewModel<T>. Also some other TreeView standard keyboard short-cuts are missing (for example right arrow to expand a node, and left arrow to contract it) are not wired up. Also it is likely that this technique will become obsolete at some point when the TreeView in the Silverlight Toolkit catches up with the WPF one and implements this trick for itself.
You can download the source code from here. And here is an image of the sample running.
I'm not sure if I missed the memo, but P&P's Composite Application Guidance for WPF (formerly PRISM) is now live for Silverlight too (AKA PRISM V2)! Download it here.
Hot on the heels of the Silverlight 2.0 release last week is a beta version of the AOL RIA mail clientpreviewed at Mix08 and built on Silverlight 2.0.
(I just signed up but who knew their contextual advertising would catch on so fast!) Although the beta is missing the "HALO" theme featured at Mix08, it does feature 3 themes including Onyx (the default, shown above) "classic" which is themed similarly to a number of other AOL web properties, and a Hubble space theme.
Cursory analysis of the app suggests the vast majority of it is built in silverlight, including (it seems) the editing widget which at the time of Mix08 was still being done with DHTML. We'll do more digging and let you know.
Both Silverlight 2.0 and WPF support the notion of resources, which can be associated with almost any element - in both SL and WPF the widely inherited-from FrameworkElement (and in WPF the FrameworkContentElement) class exposes a Resources property of type ResourceDictionary. The Resources dictionary is a simple collection of key-value pairs. Almost anything can be stored as a resource, from brushes to templates, data sources, converters, dates, strings and any other .NET object which can be represented as XAML. The key used to retrieve resources can be anything too; however strings or static fields are used.
The current (beta 1) implementation of Silverlight 2.0 has some notable differences to WPF however. The first is that resources cannot be factored into separate files and referenced using the <ResourceDictionary.MergedDictionaries> feature of WPF resource dictionaries. This is unfortunate as it means that the App.xaml file will probably become large and unweildy (and potentially an integration pain point between developers and designers) in Silverlight.
Another notable difference is the way resources are retrieved in code. In WPF FrameworkElement and FrameworkContentElement have methods FindResource and TryFindResource which will look for a resource in the current dictionary with the key provided. If no resource is present for this key these methods traverse the logical tree to ancestor nodes looking for the resource that matches the key. Silverlight 2.0 beta 1 does not expose methods like these (possibly due to the de-emphasis of the separation between the visual and logical trees as concepts in its programming model). You can refer to resources on an object by their key, but no tree searching is performed - if the resource doesn't exist in that resource dictionary then null is returned.
As with WPF, resource retrieval in XAML is done using the {StaticResource} markup extension in Silverlight 2.0. When this markup extension is used the tree is traversed looking for a resource with the specified key. There is no {DynamicResource} markup extension in Silverlight 2.0.
In Silverlight 2.0 Resources can either be given a key (by setting the x:Key attribute) or a name (by setting the x:Name attribute) and both will work for item resolution. Attempting to add two elements with the same value (one by setting the key attribute, the other by setting the name attribute) results in a run-time error.
Silverlight 2.0 promises to bring much of the goodness of WPF to the browser. So how does one of my favourite WPF features - data binding - fare in the new Silverlight 2.0 beta 1 world? To help answer this question I drew up the following summary:
| Similarities |
Differences |
|
Binding Object – the Binding object is present in both SL 2.0 and WPF. Many simple binding scenarios will probably work between the two without modification, but if you’re using the more complex properties of the Binding object in WPF you’ll need to revisit that for Silverlight 2.0 code. The INotifyPropertyChanged interface is also used for change notifications on data objects to be propagated back up to the binding infrastructure. |
Binding Object – although the Binding object exists in SL 2.0 and WPF the SL 2.0 version is very pared-back compared to WPF, having only 5 properties: Converter, ConverterCulture, ConverterParameter, Mode and Source, in contrast to the 20 or so relevant properties the WPF binding object exposes or inherits from its base types. One of the most key properties on the WPF binding object – the path isn’t even a property at all on the Silverlight equivalent. Instead it is specified as a constructor property. Also the Path in SL 2 can’t drill down into indexes or attached properties the way it can in WPF, however you can still access sub-properties on objects. Josh has some screen-shots from Reflector showing the difference in size of the two types. |
|
Data Context – the concept of a Data Context for a control which is propagated from a parent control down to child controls is shared between WPF and Silverlight 2 beta 1. As with WPF the FrameworkElement type adds the DataContext property in Silverlight 2.0 beta 1. |
Binding Markup Extension – although syntactically quite similar (albeit with less properties) bindings in Silverlight are quite different internally to their WPF counterparts because they don’t use a managed Binding Markup Extension. In fact, from what we can see of Silverlight 2.0 beta 1 there ARE no markup extensions of any kind. The Silverlight documentation discusses them here but they don’t appear anywhere in the object model. Presumably the implementations of the various markup extensions are hard-wired into the Silverlight runtime. |
|
Converters – One of my favourite extensibility points of WPF has been completely migrated to Silverlight 2.0 beta 1 (possibly due to the simplicity of the IValueConverter interface). A converter and converter parameter can be supplied as part of a binding. |
Binding to Other Elements – one common scenario is to bind two pieces of WPF UI to each-other. For example binding a slider to the “zoom” on a ScaleTransform. This is done by setting the ElementName property to the name of the element in the current name scope. Silverlight 2.0 beta 1 doesn’t support ElementName as a parameter when binding. This limitation can be worked around fairly easily by creating a simple object with a single property of the type you wish to glue together (double is probably the most common scenario) and then implementing INotifyPropertyChanged on that type. This approach is described in more detail here. |
|
Data Templates – Both WPF and Silverlight 2.0 beta 1 share the concept of templates that can be applied to data. One area where SL 2 differs is that in WPF you can specify a template by the type of object the template applies to (by setting the DataType property). If this is set and no key is supplied (and the Datatemplate is appropriately scoped) the template becomes the default appearance for that type of data item in WPF. The DataTemplate type in Silverlight 2.0 beta 1 doesn’t include this property so all data templates are “keyed” in resource dictionaries or entered in-line. |
Data Triggers – Data templates in Silverlight 2.0 beta 1 don’t have data triggers like their WPF counterparts. This can be worked around using a converter, but requires more code than a data trigger would. Given the changes introduced by the new Silverlight control templating model data triggers going missing are the least of your worries. |
|
TemplateBinding – TemplateBinding is fundamental to styling of controls, and thus has also made its way over from WPF to Silverlight. |
|
|
ObservableCollection
- the generic collection with built-in change notification, ObservableCollection has also been included in Silverlight 2.0 beta 1. The INotifyCollectionChanged interface (the collection equivalent of INotifyPropertyChanged) is also present, and implemented by ObservableCollection.
|
|
I was pouring over the Silverlight 2.0 tutorial posted by Scott Guthrie, and noticed this entry which describes the currently unreleased DataGrid for Silverlight (due for a beta1 release at Mix08 in a few weeks presumably). The new beta release will also include a calendar date-picker controls (also noticable omissions from the current default set of WPF controls) as well as integral features from WPF such as data binding, and layout management.
Scott recently also mentioned a DataGrid for WPF (in addition to a number of other improvements) as part of the Client RoadMap, although without any date commitments this looks a bit further out. This is interesting, as it shows Silverlight pulling ahead in some areas of its larger and older sibling WPF. Of course there are a number of 3rd party grids available for WPF, including a free DataGrid from XCeed.
The project formerly known as Windows Presentation Foundation everywhere (WPF/e) has been re-named Sliverlight in preparation for its final release. Prior to WPF/e it was known as Jolt. Silverlight is a cross-platform and cross-browser plugin for creating rich internet experiences and applications for the web. It uses a subset of Xaml and WPF. You can read Tim Sneath's top 10 reasons you might be interested in Silverlight here.
