SysON could provide extension points to let downstream applications adapt SysON representations to their needs.
For example, an application may want to add nodes in SysON diagrams representing additional, non-SysML elements.
Currently, this can be done by removing the SysONViewDescriptionProvider bean from the application and registering a custom bean implementing IEditingContextProcessor that tweaks view models before they get added to the editing context.
This solution is clearly not optimal, since it implies to play with registered beans and replace them on the fly.
SysON could help with that by providing hooks once representations are created to let downstream applications adapt them.
Note that other customization options already exist for downstream applications, e.g:
ITreeItemContextMenuEntryProvider allows to provide custom context menu entries in the explorer (and other trees)IPaletteProvider allows to provide custom diagram palettes (including custom tools, sections, etc)
SysON could provide extension points to let downstream applications adapt SysON representations to their needs.
For example, an application may want to add nodes in SysON diagrams representing additional, non-SysML elements.
Currently, this can be done by removing the
SysONViewDescriptionProviderbean from the application and registering a custom bean implementingIEditingContextProcessorthat tweaks view models before they get added to the editing context.This solution is clearly not optimal, since it implies to play with registered beans and replace them on the fly.
SysON could help with that by providing hooks once representations are created to let downstream applications adapt them.
Note that other customization options already exist for downstream applications, e.g:
ITreeItemContextMenuEntryProviderallows to provide custom context menu entries in the explorer (and other trees)IPaletteProviderallows to provide custom diagram palettes (including custom tools, sections, etc)