[rkward-tracker] [ rkward-Feature Requests-1189713 ] make plugin system more modular and generic

[SourceForge.net]

Feature Requests item #1189713, was opened at 2005-04-25 20:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=459010&aid=1189713&group_id=50231

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Thomas Friedrichsmeier (tfry)
Assigned to: Nobody/Anonymous (nobody)
Summary: make plugin system more modular and generic

Initial Comment:
This is one of my long-term TODOs. I'm placing 
it in the Feature-Tracker in order to have a place, 
where I collect my thoughts about how this can 
be done. Consequently, some information in 
this tracker-item may be rather cryptic. Sorry 
about that. 
 
The plugin system should be reworked to be 
more modular. At the core there will be a class 
like "RKPluginComponent". 
 
The main ideas are: 
- Plugins should be able to simply "include" 
certain components. E.g. a plugin to calculate a 
correlation could include a component to 
generate a scatterplot for this relation. 
Improvements in the scatterplot-component 
would automatically be available in the 
correlation plugin, and there would be no need 
to duplicate code. 
- 
https://sourceforge.net/tracker/index.php?func=detail&aid=1069570&group_id=50231&atid=459010 
Allowing a notebook or SEMMA-approach, i.e. a 
GUI-variant where you simply connect a series 
of calculations to each other 
- Easy hooks to create plugins / plugin 
components using e.g. pyQt. I.e. implementation 
of a plugin / component should be easily 
possible in different languages. 
 
 
A plugin-component will have several 
components: 
 
- A list of named input slots: 
For instance a component to transform a vector, 
will have an input slot for a numeric R object. 
- A list of named output slots: 
Also this component will have an output slot for 
a (transformed) numeric R object. 
- A QWidget derived GUI, allowing to set some 
options (e.g. type of transformation): 
There should be specialized input slots for each 
option settable in the GUI, so those options can 
be set from outside 
- Further specialized input slots, e.g. controlling 
the visibility / enabledness of the GUI options 
 
 
Each plugin component will have to implement 
certain calls. Most importantly the 
code-generation function currently executed 
(exlusively) in PHP: 
preprocess (), calculate (), printout (), cleanup (). 
The plugin component will have to return 
meaningful (or empty) R-code on each of these 
calls depending on its settings. 
When used as a standalone plugin, this will 
work roughly as it is now. When included in 
another plugin, the including plugin will have to 
also "include" those code-sections. 
Each component may rely on the current 
PHP-backend to accomplish code-generation or 
use its own mechanisms. 
 
 
Further ideas: 
- Special components that can be used by the 
main app, e.g. as import/export filters 
 
 
Main problems (incomplete list): 
- Find a good description of input/output slots. 
This will have to include information on types of 
input allowed / output generated, whether an 
input is mandatory, whether an output is 
available with current settings, etc. 
- Find out how e.g. pyQt-generated QWidgets 
can be integrated in ones generated by rkward. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=459010&aid=1189713&group_id=50231