SDA SE Wiki

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

User Tools

Site Tools


Subsystems

creating components vs. supplying services

Example prologinterface. The PDT offsers a service in terms of an iprologinterface. To realize that service it creates and configures an instance of the 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.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 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, 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 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 implements the viewpart interface. When the view part is needed, it gethers all neccesary information and configures a 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