Application Development Meanderings

When thinking about eclipse’s new e4 approach of using an EMF model to represent the “application” and thinking about the easy at which you can specify XAML, you want to draw some comparisons to help understand what problems are being solved. The EMF-based application model in e4 represents the new way that an application is specified, potentially from different modules that are enhancements or plugins to the main application. At first glance, EMF looks like overkill (over designed) but when you draw some comparisons to how XAML works, you realize that there were reasons why EMF makes a good choice and what kind of trade-offs you have , say, compared to the easy of specifying XAML. While the e4 team does emphasis it’s a modeled model, its not always clear why that’s useful or if it in any way matches what XAML does. Here’s a few thoughts about e4 and XAML that will be explained more in the table but are true for both The interface, for the most part, is specified declaratively. W

I was recently coding a data entry screen for a WPF application using a type data set. The typed dataset had a data table that looked like: Entity: Order Id Name ParentOrderId: Optional, nullable, no default “id” assigned to it It is a recursive relationship. The data column allows nulls because it is an optional relationship and no default values are set on the field. In the WPF data entry screen I needed to have a combobox that allows a user to set the parent order. I am also using a MVVM model to bind to the data context of the toplevel UserControl. The question is, how do I setup a combox box to handle potential nulls on the FK? Here’s some XAML: UserControl ... Name="TheForm" > <!-- The master part of the form displays a datagrid of orders --> <!-- The detailed part of the form below has the selected item of the datagrid as its data context --> < ComboBox ItemsSource ="{Binding Path=DataContext.Orders, ElementName=TheForm}"