10.5. Summary
There were a lot of details covered in this chapter. Although most of it was specific to the Hyperbola application and XMPP, it's worthwhile to step back and see how the experiences apply more generally to your RCP applications.
If you are going to use non-Eclipse libraries, they need to be bundled into Eclipse plug-ins. Bundling the libraries does two things: describes the library to other plug-ins (e.g., what classes are available at runtime) and adds these classes to the build path. See Chapter 20 for more details on bundling. We can't say this enough: Separate the UI from the domain model. Build actions that manipulate the model and UIs that update accordingly. This makes your application easier to test and evolve. Many applications take this one step further and split the UI classes from the domain model classes into separate plug-ins. This is a popular pattern with Eclipse platform plug-ins, where related plug-ins are split and post-fixed with "core" and "ui" to differentiate them. We have not done this here just to keep things simple. The examples in Chapter 23, "RCP Everywhere," go into plug-in structuring in great detail. Your domain model is important and is something that is not addressed by Eclipse. Eclipse does, however, provide frameworks such as the extension registry and reusable UI components that make it easier to quickly get a product-quality application running. As we mentioned at the outset, this is the power of the Eclipse RCP. It is all the middleware code that you need to have but don't really want to write.
If you had trouble following along with all the code changes, import the code for this chapter and browse it to see the complete picture of changes that occurred.
 |
