We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The current way of handling actions works great for small plugins, however, for larger ones, it gets a bit messy.
Add the possibility for Actions and Connectors to be classes that extend something from the SDK.
Basically an abstract class such as:
abstract class TPInvokable<T extends TouchPortalPlugin> { protected final T touchPortalPlugin; public TPInvokable(T touchPortalPlugin) { this.touchPortalPlugin = touchPortalPlugin; } public abstract void onInvoke(); public abstract void onListChanged(TPListChangeMessage tpListChangeMessage); }
TPAction
TPConnector
Developers would then have to register those to the TouchPortalPlugin before connecting
TouchPortalPlugin
// Plugin class public class MyTPPlugin extends TouchPortalPlugin {} // TPAction class @Action(name = "Action One", categoryId = "BaseCategory") public class ActionOne extends TPAction<MyTPPlugin> { @Data private String param1; public ActionOne(MyTPPlugin myTPPlugin) { super(myTPPlugin); } @Override public void onListChanged(TPListChangeMessage tpListChangeMessage) { // Update Specific Choices } @Override public void onInvoke() { // Do stuff } } // Later when the plugin starts MyTPPlugin myTPPlugin = new MyTPPlugin(); myTPPlugin.register(ActionOne.class); myTPPlugin.connectThenPairAndListen(myTPPlugin);
The text was updated successfully, but these errors were encountered:
I think this would be a really nice addition to the SDK!
Sorry, something went wrong.
core: (WIP) Modularization closes #54
bfd7e4a
ChristopheCVB
Successfully merging a pull request may close this issue.
The current way of handling actions works great for small plugins, however, for larger ones, it gets a bit messy.
Add the possibility for Actions and Connectors to be classes that extend something from the SDK.
Basically an abstract class such as:
TPAction
would extend it as isTPConnector
would extend it and also add the necessary implementation to handle the ConnectorValueDevelopers would then have to register those to the
TouchPortalPlugin
before connectingThe text was updated successfully, but these errors were encountered: