Chart Wizard

Last modified by Vincent Massol on 2020/02/14 12:36

 Feature
 Idea

Description

Spec:

Consolidate Chart.js and/or D3 macros into an easy to use macro that functions and feels like MediaWiki's Graph tool. A few basic chart types should be provided "pre-configured" but should also serve as a tool to allow users to leverage the full capability of these libraries (i.e. expose the code and allow editing). Secondary feature: ability to copy paste excel cells into step 2 of the wizard. Not necessarily printable but definitely exportable to PDF

Analysis & Cost

  • (option) Modify PDF export feature to use client-side HTML(+CSS) DOM - 8d
    • Inject Export button from JS (JSX)
    • Take images for Canvas since it's not in the DOM
    • Send client-side HTML to XWiki Export Action
    • Need to handle protection as otherwise any arbitrary HTML could be sent to XWiki to transform into PDF
    • Modify XWiki Export Action to use this HTML instead of rendering from the document
    • Inline CSS within the HTML (for ex with https://www.npmjs.com/package/inline-css)
  • (option) Handle multi page exports (spaces or wiki) - 3d
    • Provide a JS-based UI to select the pages to export
    • Use a hidden frame to load all the pages to export and get the HTML/CSS to send back
  • Implement a simple generic wizard that can work for all chart macros ({{chart}}, {{chartjs}}, {{d3js}} or any future ones)
  • Have the concept of Chart Templates, i.e. a script that generates the graph macro applied with wizard variables bound in the script context.
  • Ability to add/remove/edit chart templates in the Admin UI - 3d
    • Note: a chart template is very generic and specifies the macro it uses to generate the chart at runtime
    • XClass so that chart extensions can contribute new chart templates. 
  • Provide a wizard with several tabs or steps
    • Tab 1: select the chart template + basic parameters such as size, padding, etc - 5d
      • Filterable template picker, each template has at least a description + type of chart
      • Show a preview based on demo data
    • Tab 2: source. 2 main sources: spreadsheet like and a reference to a table in a wiki page somewhere (document reference + HTML id attribute for ex). - 2d
      • Demo data
      • + Ability add lines and columns (ideally constrained by the chart type)
    • Tab 3: raw data (depends on first step) - 0.5d
      • displays the chart template applied to entered variables and allow the user to make changes. 
  • Introduce a new {{chartwizard}} macro - 3d
    • Saves the chart wizard data (all fields), either as parameters or in the macro content
    • Note: also save the raw data IF the user has made modification to it
    • Note: the chart template used is also saved with its id
    • At view time the {{chartwizard}} macro applies the chart template with the provided data. If raw data has been provided by the user then use it instead of rendering the chart template.
    • This allows customization by users if needed while allowing generated graphs to look the same across the wiki for the nominal case
  • Add a WYSIWYG icon for starting the chart wizard - 0.5d
  • When double clicking the {{chartwizard}} in the WYSIWYG editor, call the chart wizard UI - 0.5d
    • Note that this should reuse the mechanism defined in SR2 (Citations) for binding a macro to a vm
  • (option) Ability to copy paste excel cells in step/tab 2 of the wizard - 2d
    • Need HTML cleanup (similar to office import)
  • (option) Have a blacklist of macros in the WYSIWYG Macro Dialog list - 0.5 day
    • To allow removing the {{chartjs}} macro from being listed to force users to use the chart wizard

Total Cost:

  • Main work: 14.5 days
  • All options: 13.5 days

Unresolved questions:

  • Do charts need to be printable? If so then hard with JS-based solutions such as ChartJS or DSJS. Note that this is why our {{chart}} macro is based on JFreeChart.
  • Need minimal list of chart types and options in the wizard (or same as MW?)
  • Not sure we can parse the full syntax from chart macros and not loose data when serializing back. Would that be acceptable?
  • Is it really needed to be able to edit a generated graph? This makes it a lot more complex. 

 


Tags:
Created by Vincent Massol on 2020/02/14 12:34
    

Get Connected