The sys base is intended to provide a consistent single definition of a set of "system" entities. These system entities should form a shared ontology for services built on Seneca. Plugins should define sys entities that cover common service and business logic use cases—for example: seneca-user defines: sys/user, sys/login, etc.
User code should not define new sys entities, but should instead define entities in their own base. The recommended name for the default base for user code is a short prefix referencing the specific project or company. For example, if Hooli were to choose a default base company wide, it should be hooli. If Hooli started a project called XYZ, then the base should be xyz. Baseless entity names can also be used, but will limit pattern matching options later, and are thus better for unit tests.
The sys entities are intended to be used directly by user code, with plugins providing only base functionality. However this raises the issue of extensibility and future compatibility. Future versions of system plugins will add additional fields to the sys entities. Since Seneca follows Postel's Law, both system plugins and user code should anticipate additional unknown fields and not blow up when they are present—they are to be copied and ignored.
However user code itself is free to add new fields to sys entities as needed, which may conflict with new system fields in the future. To prevent this, Seneca Entities should have the capability to control field names, disallowing new fields that do not contain specific formats. Suggestion: sys entities may be extended by user code with new fields where the field names contain an underscore (_) (this is much like the convention for custom html tags).
This means that system plugins must adhere to the rule of not using underscore in field names. A review is needed of system plugins to ensure this is the case.
The
sysbase is intended to provide a consistent single definition of a set of "system" entities. These system entities should form a shared ontology for services built on Seneca. Plugins should definesysentities that cover common service and business logic use cases—for example:seneca-userdefines:sys/user,sys/login, etc.User code should not define new
sysentities, but should instead define entities in their own base. The recommended name for the default base for user code is a short prefix referencing the specific project or company. For example, if Hooli were to choose a default base company wide, it should behooli. If Hooli started a project called XYZ, then the base should bexyz. Baseless entity names can also be used, but will limit pattern matching options later, and are thus better for unit tests.The
sysentities are intended to be used directly by user code, with plugins providing only base functionality. However this raises the issue of extensibility and future compatibility. Future versions of system plugins will add additional fields to thesysentities. Since Seneca follows Postel's Law, both system plugins and user code should anticipate additional unknown fields and not blow up when they are present—they are to be copied and ignored.However user code itself is free to add new fields to
sysentities as needed, which may conflict with new system fields in the future. To prevent this, Seneca Entities should have the capability to control field names, disallowing new fields that do not contain specific formats. Suggestion:sysentities may be extended by user code with new fields where the field names contain an underscore (_) (this is much like the convention for custom html tags). This means that system plugins must adhere to the rule of not using underscore in field names. A review is needed of system plugins to ensure this is the case.