Development principles

The framework is designed with flexibility in mind.
In order to avoid complex data-flows through a plugin a developer may choose to follow these recommendations:

• Think event-based.
  The framework is based around events and developing a plugin in the same manner reduces the complexity of the whole

• Avoid static and singletons
  Static data (such as singletons) interrupts the data flow through the code.
  Avoiding use of this feature allows for more clear data flow concepts to develop.
  We recommend constantly repeating the following question during development:

  How does this influence other instances of the plugin/framework in the same JVM?

• Think decoupled! When developing a plugin "A" that optionally interacts with another plugin "B", consider developing a bridge-plugin "C" instead of making "A" explicitly depend on "B". This will allow administrators to use "A" without having to install "B"s API module.
  This can be done within the development workspace of "A" by using an additional source set. (Therefore, the developer does not have to maintain multiple projects to provide bridges.)

📘

Remember

Not only a plugins developer (and its contributors) need to understand how a plugin or process work. Sysadmins also count on being able to detect and fix errors when they arise.

Also: If you fell like you can't come up with a way to abide these principles, always feel free to get in touch with others in the community.

While it is normal to violate principles when creating a rough draft and concept development, we encourage developers to uphold these principles at least from their first full release candidate.