You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Python plugins work great as standalone files to run. However, there are cases where you might want to reuse some aspects of the code written for one plugin in another. Currently, we run into this problem, where in multiple analytics could be run on a GMESubTree, but all those analytics do a transformation of that SubTree to PySpice/SPICE format. The resolution we found is via inheritance. Wherein, we first subclass the PluginBase from webgme_bindings and use that class elsewhere for our plugins. Now, we could argue about Composition vs Inheritance all day, but the problem we face is two folds and doesn't resolve either using Composition vs Inheritance .
Since Python plugins are run as standalone files, importing/inheriting common Plugin code is a bit of a pain and relies on some importlib features offered by Python.
Standalone python modules like utils, that don't require webGME specific concepts but could be used in multiple places has to be defined in the class / module file itself. Causing import issues as well.
A solution could be refactoring the common code into a separate Python package, which could be imported/used freely.
The text was updated successfully, but these errors were encountered:
Python plugins work great as standalone files to run. However, there are cases where you might want to reuse some aspects of the code written for one plugin in another. Currently, we run into this problem, where in multiple analytics could be run on a
GMESubTree
, but all those analytics do a transformation of thatSubTree
toPySpice
/SPICE
format. The resolution we found is via inheritance. Wherein, we first subclass thePluginBase
fromwebgme_bindings
and use that class elsewhere for our plugins. Now, we could argue about Composition vs Inheritance all day, but the problem we face is two folds and doesn't resolve either using Composition vs Inheritance .webGME
specific concepts but could be used in multiple places has to be defined in the class / module file itself. Causing import issues as well.A solution could be refactoring the common code into a separate Python package, which could be imported/used freely.
The text was updated successfully, but these errors were encountered: