I sat in on the “Modeling the Workbench” breakout session at the E4 Summit.
Before I go too far, it’s worth pointing out that there is a lot of activity going on here and I’m only able to capture some small part of it. The information that I’m capturing is my perception of what’s happening and may not accurately reflect reality
There is a consensus that a consistent underlying object model is required for the workbench. Currently, at least in the Eclipse platform itself, there is a relatively good ethic of having a user interface model (a là model-view-controller pattern); the problem is that there is little consistency. Each component has a different, custom-rolled model. The notion of a DOM has been discussed heavily. The basic idea is similar to that of a browser: to change what the user sees, you change the DOM. Changes in the DOM are reflected in the user interface. This opens the door to the use of CSS to control of the workbench presentation. Of course, EMF is a great candidate for modeling the workbench. It was discussed, however, that other technologies (including databases) might be considered (or at least left open as options).
One of the more interesting things discussed (and the source of the title of this post; I’ll leave it as an exercise for the reader to find the popular culture reference) is the use of a bus in place of the bajillions of listeners currently used. It’s like a light-weight in-memory version of an Enterprise Service Bus (ESB); though I could see it being a cross-process thing. Rather than setting up many individual relationships between JavaBeans and user interface components, the selection service, part listeners, etc., a small number (possibly one) of buses can funnel changes into a single point. Today, for example, a view will register listeners on the (potentially) thousands of objects displayed in table. Imagine instead, registering a single listener on a bus that will notify you when any attribute in one of those thousands of objects changes. Rather than implementing my domain model as JavaBeans with bound properties, I instead just drop and event on the bus and let it tell everybody who cares. It makes sense. It reduces the amount of work that results from a change (especially if you have a decent filtering mechanism). It simplifies the development model which should lower the barrier for entry to everybody. To boot, by including an ESB, we have greater buzz-word compliance. I wish I’d thought of it.
Remember that these are all just ideas. You need to get involved in this conversation. The E4 page provides some useful links for getting involved including the mailing list, and the IRC channel. Of course, the E4 page is on the Eclipsepedia Wiki, so you can add your input there as well. If you want to check in on the E4 summit, you can connect to the web cam.
