Application Development Meanderings

CNF is part of the eclipse API that provides a general navigation framework (a tree object) with content that can be provided through eclipse plugin.xml extensions. The hard part though is understanding how to get certain types of content to be linked (bound) to specific content and label providers. For simple hierarchies, this is not a big deal, but for complex hierarchies where the content is spread across plugins and navigation content is provided through multiple specifications of org.eclipse.ui.navigator.navigatorContent extensions. The tricky part is the triggerPoints and possibleChildren specifications. When is each used? Should you always duplicate content into both of these sections. The enablement element is actually provided so you can do exactly that. The only true answer comes from looking at the source code. Since content extensions are provided through plugin.xml specifications and navigatorContent components are lazily instantiated, the underlying CommonViewer uses a c

I was looking through some projects and came upon orchestra from apache as part of teh myfaces project. It provides a generic mechanism for conversations. It is geared towards web applications but the framework appears to be quite general, depending on spring scopes, and potentially can be used in rich client applications. I'll investigate and post back here to this blog. I can report back that it all works for rich client applications. Even though it uses spring scopes (where one could just use annotations or conversation names), the framework works. For rich clients, you need a different configuration approach than listed in the myfaces documentation that composes the umbrella project of which orchestra is a subproject. You need to do this once somewhere: FrameworkAdapter.setCurrentInstance((FrameworkAdapter)getBean("orchestraFramework")); Here, I have a method in the same class that has getBean() obtain a bean from the toplevel application context. In that toplevel c

Eclipse uses plugins for modularity. The plugins often specify content directed towards the presentation layer (the UI). In many extensions, class names are specified to indicate which class should be used for certain jface and SWT classes, for example, specifying a jface content provider such as ITreeContentProvider. Since the eclipse plugin actually creates the class using this class name, you do not always have object lifecycle control over it. Note that a class specified in the plugin could implement the IExecutableExtensionFactory or IExecutableExtension interface however you may need to have access to the input object to properly create the specified class. If you need the input data to fully initialize or create the class through those executable extension interfaces, then the pattern below will be useful to you. You can also specify a factory class in extension points instead of a class name. The factory will be used to create the instance object. If the factory knows a well-

Here's something that is bugging me a bit. In XAML, you can specify data contexts and automatically created hierarchical resource contexts (Resources) fairly easily in markup. In eclipse, say for the common navigator content specification, you specify label and content providers in XML. Then set the input into the common navigator (which is really a tree viewer) in code. I'm okay with the setting the input in code, however, I am unable to control the lifecycle of of the label and content providers directly and hence, cannot do spring initialization and bean post processor tricks to help set properties and behaviors that are really configuration issues (including property dependencies). I guess the only thing to do is to call specific "processors" to run on the label or content provider explicitly in the Viewer.setInput() method when it is called or connect up the instance of the laber or content viewer using a customized FactoryBean that dynamically connects (at the

I was reading through MSDN documentation yesterday and it struck me that the Resources feature in XAML is actually a bean factory in the world of spring. It looks different, but the idea of storing objects defined in XML and making that accessible, and having hierarchical contexts was pretty much like spring. It makes you realize that using spring at a more fundamental level inside of RCP applications could be a good idea. The hierarchical contexts appear to be automatically assembled based on the scope of the resources e.g. Windows.Resource versus Page.Resource I believe are automatically nested. On a separate note, DataContext looks to be the same as a hibernate Session although .Net DataContext has more support for data binding and other features. The DataContext provides identify scoping boundaries, has connection information, etc. The real issue for the eclipse RCP is that the jface GUI elements do not allow more lifecycle control when defined in the plugin extensions. The plugins