Quantcast
Channel: SCN : Blog List - SAP BusinessObjects Lumira
Viewing all articles
Browse latest Browse all 855

Best Practices for Visualization Extensions

$
0
0

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
  • Hight quality blog: to get the right attention
  • High quality presence on github: to make the extension easy to consume.


 

Developing Extensions

Even though open sourced extensions are not formally SAP extensions, we request that simple guidelines are followed to ensure base 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.
  2. No modification of global state
    JavaScript code, including libraries, should be defined within your extension as Asynchronous Module Definitions compatible with requirejs. Code should not create top-level objects because this leads to conflicts between extensions. Do not modify the global requirejs context (such as by installing requirejs plugins), but do feel free to require the "require" module, modify its context and then use it for loading resources.
  3. No access to DOM outside of container
    Extension code must not access or modify the document outside of its assigned container. The DOM is not a public interface and will change between versions.
  4. No disallowed dependencies or resource access
    Bundles should access only their own resources and external-to-Lumira resources. Accessing or referencing paths within Lumira but outside of the bundle, such as to a different extension, is not safe. Do not hard-code paths to resources within your bundle that reference locations outside of your bundle (like "/sap/bi/bundles/mybundle/myresource"). Assume that the extension's root location will change and construct the URL dynamically. This can be done by requiring the "require" module and calling its toUrl() function.
  5. Vendor metadata contains either employee’s name or “Community Contribution”
    The vendor name in the feature file (extname-feature.json) should either be your own name or “Community Contribution” if you prefer. The vendor name value in this file corresponds to the value that was entered for "Company Name" during project creation in Web IDE. We’re no longer putting “SAP” in this field, since these extensions would show up as 'created by SAP' in the extensions manager and thus create an expectation that these extensions are indeed created and supported by SAP. Of course, that is not the case.
  6. Avoid hard coupling between the code and data structure
    • No direct reference of column name
    • Allow dynamic number of measures in a measure set, if applicable (e.g. make use of d3.keys())
    • Reference dimension sets and measure sets by their name for better code readability
  7. Choose SVG rather than DIV
    It is recommended to use SVG for rendering your data visualization charts rather than using DIVs. SVGs serve the purpose better for drawing canvases and rendering chart components, something that DIVs are not quite up to the mark with. Also, the new SAP Web IDE works better with SVG-based extensions.


 

SCN Blog

For us to publish an open source extension, we request that it is acompoined by a blog on SCN. The blog will be your 'business card' and should follow certain content recommendations: to increase popularity both of the blog and the extension.


  • Section 1
    Short description / summary

    What exactly is this extension, what business need is it addressing? This section can be placed on the left hand side, covering 75% of the width of the blog space.


  • Section 2
    Link to GitHub repository

    Preferably at the top right corner of the blog so that people don't have to scroll down. This section can be placed adjacent to Section 1 on the right hand side, covering the remaining 25% of the total width.


  • Section 3
    More details about
    :
    • Business need / challenge you are addressing. Why this chart, data access extension?
    • Explain the used data set (which is included in github)
    • Demonstrate how to use the chart including Dimensions & Measures used
    • How did you go about developing the extensions - lessons learned, things to avoid

      This section can continue below the first two adjacent sections and cover the entire width of the page.


  • In any section
    Screenshots
    (e.g., of the visualization). Add a video, if you have one (e.g., YouTube)

 

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: suantak.niangneihoi@sap.com


Viewing all articles
Browse latest Browse all 855

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>