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}"

LAST UPDATED: October 10, 2010. This blog will cover creating an e4 and EMF example application. It uses teneo as the persistent store to store the data modeled in EMF. The example is complete start to finish. The blog is quite long but if you follow along, it should only take about 30 minutes to get a full, and useful RCP application up and running. Problem Statement You need an application to satisfy the following requirements: The domain model is hierarchical. The domain model should be extensible so that other groups who adopt the application can change the domain model to their needs e.g. add an attribute to a domain model easily. You need to display the domain model using a tree model for easy user navigation. CRUD screens should be available, in some fashion, for all domain objects. The data should be stored in a RDBMS while minimizing any framework-specific extensions or RDBMS artifacts. There is no legacy integration requirement. The application, hypothetically, requires rich

I have spent a fair amount of time with apache pivot, authoring several components and peering into the guts of the system. Apache pivot is a small, UI library that demonstrates what can be done in java and how, relatively speaking, easy it is to produce something useful that is still robust. I encourage everyone to look at the project and give apache pivot a try. Using apache pivot has brought to light a few thoughts: Pivot uses skins to customize drawing behavior. Skins can be only implemented in java code. BXML is a great tool and BXML could be used to specify skins (and hence themes and all customization) using the concepts in WPF similar to templates. Templates in WPF are essentially the skins. However, pivot forces java coding and "skin" management complexity where none is needed. In fact, the entire skin concept can be removed in the spirit of WPF with no loss of control. The complexity of implementing templates is on the order of implementing a skin--and this would al

Typically, GUI applications have the issue that the UI itself runs in its own thread and  follows some type of event-driven design. Multi-threaded GUI’s are hard to write. The event dispatching model will typically have a way to run tasks on its  thread that works with (versus against) the UI system. In swing, the EDT is the event-dispatch-thread and performs this function for java swing. If we are running a system that is suppose to handle publishing and consuming by handlers that are typically tied to the EDT, how do we arrange for all of the channel activities to be on the right thread? One way, not so safe, is to ensure that the channel and entire infrastructure is created an runs on the EDT. We can do this by wrapping the entire program in a SwingUtilities.invokeLater(…) method to launch the program. If you look at the demo code, this is what we do. So we seem safe, at least, until we are publishing and consuming in a side thread because of a long running task or some other scenar

If you look at different event broker implementation, such as that in OSGi, contemplated for e4 and eventbus.org, they all talk about subscribing to events based on a topic string. The topic string is like a URI that denotes topics of interest and typically relate to some type of hierarchy of objects, actions, services or some combination of these. We saw in the last blog that is fairly easy to implement a subscriber type mechanism that selects on an event type and an arbitrary SpEL expression (AND’d together). Combined together with spring integration’s method injection, we can also have a flexible method signature. How would we implement event topics specified as URI-like strings? You can also think of these strings similar to RESTful URIs that denote traversing a container hierarchy. Seems useful. In addition to topics, we also may want to filter events that we process based on the source in some way. While we do not want to go back to the tight coupling associated with the classic

In Part 1, we saw that loosely coupled integration with legacy components is alot of work mostly because of the need to create scaffolding around error handling, method invocation, publishing and channel management (routing, filtering, bridging). In this blog, we want to assume that a loosely coupled model is the implementation approach and that spring integration will be used to implement it. Essentially, we are saying that the application context message publishing model is a good one and we want to put the simple event publishing mechanism that is provided in the application context today, with framework provided by spring integration. Because we can assume that the components, where appropriate, will be loosely coupled and that spring integration is the implementation machinery, we can program interfaces, create subscription annotations and do many things that are one step closer to the application specific nature of the integration. Spring integration cannot make many assumptions