Well, I figured out how to get the buttons to enable or disable according to what the application’s state is (what fields are populated, etc). Thanks entirely to JFace.
I did this by creating an Application state class, which is basically a glorified HashMap that also propagates “state” (property) changes to any registered listeners. Then, for every action that needs to pay attention to a property, I added the JFace’s IPropertyChangeEvent interface and registered them with the ApplicationState object. So, now I have a central place to put and retrieve application data that also propagates all update events. I could see this slowing things down in a larger application with tons of listeners, and I’m not quite sure how Eclipse is doing it, but I like what I have for this application.
ClassLoaders:
I found some thing cool that I didn’t know about ClassLoaders last night. Two different instances of classloaders do not know about classes that were loaded by the other classloader. This is huge, as it gives me the ability to classload the various KeyStoreSPI versions, and using a combination of the Delegate pattern and a generalized Interface, I can access all of the different keystore versions from my program. I will try to put up an example of what I’m talking about in the next few days. This is a really neat thing, and if you develop your code using interfaces (something the Spring Framework prescribes), you can load newer versions WITHOUT restarting… of course, you need a customer ClassLoader Manager that is able to either be informed or go out and check for newer versions, and then load the class using a new ClassLoader and give that to you client objects.
Post a Comment