There are several different plugin types in SPS. Create the piping between them so there is a common interface to work with plugins.
Ctools plugin system will be the base.
There are several different plugin types in SPS. Create the piping between them so there is a common interface to work with plugins.
Ctools plugin system will be the base.
Comments
Comment #1
indytechcook commentedUsing the Namespace Drupal\sps\Plugins\
will allow for DI plugins withotu using ctools file loading logic. The logic is not needed using xautolaod's functionality.
Comment #2
indytechcook commentedSo this idea wasn't very flexible. I went back to a more info hook based approach. I'm writing up documentation.
Comment #3
indytechcook commentedThe base plugin factory has been pushed to the plugins branch. Testing and more documentation are being worked on.
Comment #4
e2thex commentedSo I think it would be nice if all validation of the plugin happened when the plugin info is parsed and stored.
I think that all of the implements validation should get moved out of getPlugin and instead done in validatePluginInfo (which is called in loadPluginInfo).
Also in loadPluginInfo the defaults from the types should be combined into the Plugin info. I think when this is done the pluginTypeInfo will not be need at all in the getPlugin Method.
Comment #5
e2thex commentedone more thing id do not think
I think you might need to do something like
Comment #6
indytechcook commentedThis has been committed to the 7.x-1.x branch because it was merged into another branch that was merged in. I'm keeping this open to work out the final issues and tests.
Comment #7
indytechcook commentedBranch has been updated. Tests still need to be written
Comment #8
indytechcook commented@e2thex in comment #5 why do you think that new $class() will not work?
Comment #9
indytechcook commentedThis is merged in.
Comment #12
indytechcook commented