steve-community
Documentation on extensions
We planned to develop an extension to SteVe. This extension will add to SteVe the compatibility with a payment operator.
It would be nice to have some technical explanation about how to develop and integrate an extension to SteVe. I took a quick look on steve-plugsurfing repo, but understand how the extension is integrated is not so easy ...
Apart of this point, having a comprehensive overview of SteVe features would also be very helpful !
great to hear about your plans! please make/develop it open source, so that the community can benefit from it.
steve in it's current architecture does not employ a general-purpose plug-in api for extensions. such a change has a low priority. we rather use a workflow that relies on git and spring framework for coordination between core components and extension components. here is how it looks:
- we develop the "extension-integrated-steve" on the master branch of another repository (https://github.com/RWTH-i5-IDSG/steve-plugsurfing), with another branch that is in sync with master on https://github.com/RWTH-i5-IDSG/steve (we call this steve-core). every now and then, we merge the changes in steve-core with the master branch, such that latest changes in core are also in "extension-integrated-steve". for this to work without problems (read: merge conflicts), we try to minimize the possibility of changes that overlap. this brings us to the next point.
- every extension should go under "extensions" package with a unique package name. the logic and implementation should not touch any other file outside this package. unfortunately, there are some exceptional cases to this (these are related to web ui/mvc). for these cases we try to be extra careful.
- if the extension logic requires overriding a core component or adding a "hook" with additional calls, then we leverage the features of spring framework for this: our business logic resides in spring components. these classes will be scanned/loaded during start and used during the run time. since we don't want to touch a core component, we add a class that extends this core class and tell spring to use the subclass instead of the super class using the "Primary" annotation. then, the instance of this new class will be used application-wide. Example
- if the extension wants to communicate with a charging station and do something based on the response, then OcppCallback class is where the logic should be implemented. then creating the corresponding response handler, attaching the callback, and passing the handler to a dispatcher will execute it. note that the communication protocol (soap or json) is abstracted away from the developer, and is decided behind the scenes. you only need to figure out, whether it is a charging station using Ocpp 1.2 or 1.5. Example
Thanks, this informations will be usefull.
I don't known if it will be possible to opensource this extensions based on a proprietary API. But I will try to contribute to core components if it is relevant.
okay. now that you mentioned it, i can add one more point:
- if the code in core in any way blocks the implementation of extension, such that the extension has to go through hacks or workarounds in order to resolve the issue, we relax the implementation or constraints in steve-core. or, we add the feature in steve-core which then can be used in extension. for this, as you've said it, this addition should be relevant to the core.
i will add to the list from time to time, if something comes to my mind.
