FunkyKB: “Silverlight’s CollectionViewSource” and other items
Bea Stollnitz: “CollectionViewSource was added to WPF mainly to permit view-related scenarios to be expressed in XAML (so they could be tooled), and also to aid in remembering the current item of previously displayed collections. The reasons for adding CollectionViewSource to Silverlight were very different. Before the introduction of CollectionViewSource, Silverlight collections were not automatically wrapped by views – in fact the concept of “views” didn’t even exist in Silverlight 2. There was no way to sort or filter a collection (other than modifying the collection itself), or to build a master-detail scenario based on currency (although you could create a master-detail scenario based on selection). …Unlike WPF, Silverlight only wraps collections with a view when CollectionViewSource is used as an intermediary. If you simply bind an ItemsControl to a collection, no ‘default view’ will be created internally for you.”
“Data Binding Changes in Silverlight 4”
Shawn Wildermuth: “Data binding has also added the ability to specify what to show in certain cases. These cases include when the value is NULL and when the value fails to load. There are two markup extensions that support this. First the TargetNull markup extension lets you specify what to show when the bound value is null. Secondly, the FallbackValue is used in the same way but is shown when the value cannot be loaded through data binding (normally when the DataContext is null or fails to find the property on the bound object). ”
“Silverlight 3’s New Child Windows”
Jeff Prosise: “The new child window feature makes it easy to add modal dialogs to Silverlight applications. A child window derives from the new ChildWindow class, and its content is defined in XAML (of course!). So you can now embellish an application with modal popups containing rich content.” This one I overlooked inside the Silverlight 4 timeframe.
“Braindump on the Event Aggregator Pattern”
Jeremy D. Miller: “Many people first come into contact with the Event Aggregator pattern through the implementation in Prism. For my regular readers you may be shocked (shocked I say!) to know that I don’t particularly care for the way they implemented the pattern in Prism. I think the Prism implementation is clumsy and awkward to use. I despise that idiom of first getting the event aggregator, then retrieving an ‘Event’ object that I’ll then listen to. Same thing with publishing. I think it’s awkward that I have two steps (get event, then publish) instead of just saying ‘IEventAggregator.Send().’” My current preference is to use the ‘light’ messaging in Laurent Bugnion’s MVVM Light.