Open sashafirsov opened 1 year ago
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.
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
Just thinking aloud... the feature complete dev tool is quite long to make. What is MVP?
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
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:
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.