SDA SE Wiki

Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering

User Tools

Site Tools


Differences

This shows you the differences between two versions of the page.

Link to this comparison view

research:jtransformer:pdtcomponents [2018/05/09 01:59] (current)
Line 1: Line 1:
 +
 +==== Subsystems ====
 +[[prologinterface|prologinterface]][[metadataengine|metadataengine]][[commoncode|commoncode]][[consoleview|consoleview]]
 +PDTPlugin
 +==== creating components vs. supplying services ====
 +
 +Example [[prologinterface|prologinterface]]. The PDT offsers a service in terms of an [[iprologinterface|iprologinterface]].
 +To realize that service it creates and configures an instance of the [[prologinterface|prologinterface]] component.
 +==== Preferences and Component Configuration ====
 +
 +===== We are using PUSH-style configuration! =====
 +
 +  *Component instances should be configured by setting properties in their respective fascade classes.
 +    *e.g.: [[prologinterface|prologinterface]].setServerPort(4711);​
 +    *There should be no other notion of preferences or configuration within the component: No cryptic property keys, etc.
 +  *In particular, components should **NOT** try to configure them selfs in situations where this would require external information. ​
 +    *e.g.: there is no sane way the [[prologinterface|prologinterface]] could know the location of the swi executable, so it should **NOT** try to guess it. 
 +    *OTOH, whoever is using (i.e. instantiating) a component should have access to such information. Put in other words: //​Instantiating a Component encompasses the configuration of the created instance.//
 +==== How are preferences used to configure components. ====
 +
 +  *preferences (AND there keys!!) are part of the PDTPlugin.
 +    *The PDTPlugin is responsible for maintaining the [[preferencesstore|preferencesstore]],​ guessing defaults,​etc.
 +    *Preference values are associated to keys defined in org.cs3.pdt.PDT- Documentation. Meaning of each respective Preference should be documented there.(for now)
 +    * When guessing defaults, the Plugin should allow System.properties associated to a key to override the guessed default value for the respective Preference.
 +    * The default value for a property, no matter how it was gethered, should of course never override explicit user settings in the preference store.
 +  * The classes making up the [[pluginproject|pluginproject]] itself should be considered as 
 +    * The glue between the framework and our components
 +    * The code that composes our components to realize and supply services to other plugins.
 +  * The plugin project should simply form a **THIN** layer of code dealing with the integration of our components into the eclipse framework. ​
 +
 +I think the console can be seen as a representativ example of how this can be done:
 +A intermediate object is created to communicate with the framework: ​
 +org.cs3.pdt.views.[[prologconsoleview|prologconsoleview]] implements the [[viewpart|viewpart]] interface. When the view part is needed, it gethers all neccesary information and configures a [[consoleview|consoleview]] component. The implementation is very thin, and all relevant work happens outside of eclipse.
 +
  
research/jtransformer/pdtcomponents.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2019