XAML-like behavior (or not) in eclipse plugin specs for CommonNavigator

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 time setInput()) is called to the specific jface label or content provider. Perhaps that is why there is a ApplicationContext.refresh() method.

You cannot control this in XAML either. It seems that the idea of specifying a factory in place of an explicit class name, does not work. I know that dynamically created this elements (plugin.xml XML or XAML) defeats some of the purpose of tracking dependencies etc., but it would make it more flexible.

Popular posts from this blog

graphql (facebook), falcor (netflix) and odata and ...

React, Redux, Recompose and some simple steps to remove "some" boilerplate and improve reuse

Using wye and tee with scalaz-stream