Bug 380553

-- This ticket was imported from http://sourceforge.net/p/rkward/feature-requests/19 on 2017-05-31 14:48:55 +0100 --
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.