inspector of template transformation result to reveal whole transformation chain up to data source
Opened this issue · 3 comments
Problem
XSLT has been banished from development community due to lack of discoverability during development process. The best what XML stack offered was done on XSLT debugger level:
- a breakpoint on particular node in data source
- a breakpoint and step-by-step execution
- transformation rules stack and scope variables inspection
To make things worse, the XSLT transformation debugger is not available in browser.. What SaxonJS and Altova been thinking about? 😛
While those debugging capabilities are essential to code execution troubleshooting, those are not giving the live check capabilities Web developers used to: the easiness of element inspection and exploration of its properties. With shadow DOM slots it goes even further and given ability to drill into the slot source. When introducing more complex transformations, it would be essential to give same ability to drill over transformation phases up to the data source. Otherwise web development community would seek straight way of debugging the UI, most likely in JS world.
implementation notes
Whether it is a injectable into page utility ( sample ), or dev tools as browser plugin, or eventually in native browser, the underlying implementation would do the same.
- Interrupt the transform routine
- process the input XML and inject the attribute which would allow to identify the source ( like full XPath )
- process the transformation to inject the current XSLT transformation rule location into output DOM.
- To insulate the debug data it would be under own XML namespace.
- since debug data are verbose, those have to be hidden in DOM inspector by default with ability to enable visibility.
The drilling through transformations would began from the result of latest which is a DOM node in browser. The input data and transformation rule reflect the call stack level. Each level would have a reference to the previous one. Traversing over transformation stack would switch the data and transformation view to current scope.
Since data DOM and transformation in inspector always would go in pairs, the default layout would comprise 3 view
- transformation stack
- data panel with data hierarchy and current pointer in it, tabs for different data sources.
- transformation panel with current template(XSLT) and tabs of loaded templates
Just thinking aloud... the feature complete dev tool is quite long to make. What is MVP?
- Enable debugging (and discoverability) by exposing the data and template
- as "copy XML+ XSLT combo " menu item
- copy data(XML, JSON)
- copy template
- jump to custom element declaration( DCE only ), not sure about declaration in JS
- preview data and template , hover/focus on the "transformation" badge
- Ability to change the template and data inline. The template is a usual DOM in DCE and modifying this DOM can trigger instances re-render.
- ? enable debugger breakpoints and step-through. Does SaxonJS have a debug API?
The drill from UI element down to data is out of MVP but would make a next generation of dev tools.
Created browser plugin for data (XML) and template(XSLT) inspection in Chrome devtools