Best Practices for Visualization Extensions
Related Links: Overview: SAP Lumira Extensions | Learn how | OS Viz Extensions
On this page, we summarize the best practices for publishing your Open Source extensions for Lumira. These best practices aim at making your effort and contribution as successful as possible:
- High quality code: to make the extension usable
- High quality blog: to get the right attention
- High quality presence on github: to make the extension easy to consume.
Even though open sourced extensions are not formally SAP extensions, we request that simple guidelines are followed to ensure a basic level of quality.
1. CSS is name-spaced
CSS should be defined such that conflicts with other extensions do not occur. Please use classes that are prefixed by your extension ID and remember that multiple instances of your extension might appear on the same html page (in a story, report or infographic created in the compose room). For example, instead of “.lines”, “.sap_viz_ext_footballheatmap_lines” is preferred.
This is a very important point to keep in mind because if CSS class names conflict with those in other extensions, Lumira may not be able to identify unique classes and will end up in an overlap of different class definitions. This will most likely result in Lumira crashing or not properly rendering charts. Not following this practice for a particular extensions can affect all other extensions installed in Lumira.
2. No modification of global state
3. No access to DOM outside of container
4. No disallowed dependencies or resource access
5. Vendor metadata contains either employee’s name or “Community Contribution”
6. Avoid hard coupling between the code and data structure
7. Naming conventions for project files
When creating your Web IDE project, it is very important to use proper naming conventions for different modules of the project:
8. Legend & Title
When creating the Web IDE project, make sure to have Title and Legend checked and included. These can be removed later on, but we want to make sure that they are there in the project so that in case someone wants to modify an existing extension and wants to have them in the project again.
9. Avoid GPL-licensed third party code
If you must make use of third party code or libraries in your extension, make sure they are not licensed under the GPL (GNU Public License), to avoid legal complications later on, in open-sourcing the code.
For us to publish an open source extension, we request that it is accompanied by a blog on SCN. The blog will be your ‘business card’ and should follow certain content recommendations: to increase popularity of both the blog and the extension.
This section can continue below the first two adjacent sections and cover the entire width of the page.
If there are any best practices you would like to add, please feel free to do so in the comments or send me an email: email@example.com
Updated: Best practices for building and open-sourcing visualization extensions for Lumira; justifications included.