Feature Request: JSON Context + Live Context + Nearby Inference

[ForbiddenEra]

JSON Context:

Newer versions of XSLT/XPath can use JSON (and perhaps others?) as input rather than an XML file.

I see I can pick an XML file for 'auto-completion context' but it would be great to be able to use JSON as well.

Background: My web platform has always generated XML from data to use in transformations; this was great when it was based on PHP but now it's based on JS on Node using SaxonJS. Currently, it still generates XML from JS objects/JSON and it's not ideal - it could be made better if I wrote my own JSON->XML library but that's just an unnecessary step when I can pass JSON to SaxonJS instead.

My biggest problem is that the XPath syntax for most common operations, even just something like <xsl:value-of select="" /> is fairly different compared to using XML input. Having help/auto-completion for this would be awesome.

Live Context

The second idea I have is that, as mentioned above, the input for XSL Transformations is generated, often from a database or otherwise. It would be great if I could somehow link a generated XML/JSON input in a 'live' or automatic way.

I can't particularly OTOH think of the best way to really implement this, especially considering that the generated input would vary based on lots of different things, a prime example being which route is being called, eg example.com/profile could be a route showing a user their account profile with the data being generated from a database with their profile details and used with an XSL template to transform into xHTML5 - obviously that's a lot of complexity that shouldn't have to be considered within the add-on.

The best solution I can think of quickly is just having the context file watched/update anytime it's changed - then I can just have my platform dump the data to a specific file anytime it does a transformation and then manually trigger the route/transformation to generate the data for the current XSLT file I'm working on and just have that file set as the context for all XSLT files.

One alternate solution I can think of is having an option for executing a command to generate the context for each XSL file, I provide a command in the add-on settings that points to my own script and when opening an XSLT file the addon would call that command with the XSLT file as a parameter, then the script can generate the XML/JSON data for the context.

Nearby Inference

It's great that it can pick up other files but it's a bit of a pain that I have to always open them in a specific order to not get the 'spurious errors' and for me this means opening 4 files in a row.

It would be awesome if the inference would at least search the same directory as the edited file and maybe one or two levels up, perhaps configurable? or otherwise have a configuration option to specify a search path.

---

Otherwise, great work - I'm always happy to see anything happening around XSLT!

[pgfearo]

Thank you for your suggestions and feedback.

I'm especially keen to address the 'Nearby inference' problem you mention where you need to open XSLT modules in a specific order to ensure xsl:import or xsl:include instructions are applied. Directory searches for a 'master module' can be expensive performance-wise, but I will look at what options are available.

The JSON auto-completion I'm guessing would just be to assist with the ? map property-name lookup operator...as the JSON context will have been parsed into a map or array combination - I'll look into this also.

[ForbiddenEra]

Thank you for your suggestions and feedback.

No problem, like I said, it's always great to see stuff with XSLT. IMHO, it should've become the standard way to do web tempting and stuff, screw React.. JSX might have some use-cases I guess, but like.. I started web development before CSS was even really a thing - we spent so much time trying to kill spaghetti-type stuff like early days of PHP where HTML and PHP were interladen to only come full circle except now it's just JS and HTML..

I literally saw code today that was a whole React element that returned a single

with a dynamic value. Makes me want to scream! ;)

I'm especially keen to address the 'Nearby inference' problem you mention where you need to open XSLT modules in a specific order to ensure xsl:import or xsl:include instructions are applied. Directory searches for a 'master module' can be expensive performance-wise, but I will look at what options are available.

This would be great.. That's partly why I suggested starting at the current files directory and looking at siblings in that directory, then going to it's parent and checking there for xsl files and other sub-directories, but I get that it can get expensive the more it has to traverse especially without limits. I'm sure there are projects much more complex than what I generally do, but I usually have something like:

.
├── base
│   ├── _inc.xsl
│   ├── common.xsl
│   ├── defaultBase.xsl
│   ├── footer.xsl
│   ├── header.xsl
│   ├── menu.xsl
│   └── noscript.xsl
├── components
│   ├── componentBase.xsl
│   └── selectorDropDown.xsl
├── default.xsl
└── web
    ├── about.xsl
    ├── home.xsl
    ├── privacy.xsl
    └── terms.xsl

For a website sort of thing.

The JSON auto-completion I'm guessing would just be to assist with the ? map property-name lookup operator...as the JSON context will have been parsed into a map or array combination - I'll look into this also.

That would be great; I haven't had much experience using any of the newer operators for this kind of stuff, having auto-completion w/JSON or (I guess supported other types of input that would get parsed into maps/arrays/whatever else) would be awesome!

Thanks for responding and making the plugin in the first place!