Use url for customLibraries

[jgroom33]

Goal: Use a custom library stored on github gist or in a repo

the schema for hediet.vscode-drawio.customLibraries allows [file,url,xml,json]

Using url does not work.

{    "hediet.vscode-drawio.customLibraries": [
        {   "libName": "foo",
            "url": "Uhttps%3A%2F%2Fjgraph.github.io%2Fdrawio-libs%2Flibs%2Ftemplates.xml",
            "entryId": "foo"
        }
    ]
}

OR
{    "hediet.vscode-drawio.customLibraries": [
        {   "libName": "foo",
            "url": "https://jgraph.github.io/drawio-libs/libs/templates.xml",
            "entryId": "foo"
        }
    ]
}

Result:

Related #182

[jgroom33]

@hediet the fix for this might be necessary in the upstream: https://github.com/jgraph/drawio-desktop/issues/235

[hediet]

If you change the remote template, would the diagram change too? Or are templates inlined into the diagram? I'm not so sure whether this feature is such a good idea in general if the former is the case.

You can also use file instead and reference a template that you can put into your repository.

[jgroom33]

the diagram would not change. Once a template object is dropped it is not tied to the parent.

The preference is to use any publicly hosted template library. Benefits:

• No static template files in repos with the diagrams (imagine trying to version control that for a widely used template library)
• No need to add more libraries to the upstream drawio project
• No need to make a vscode plugin just for a template library... example

[hediet]

I also don't like that a malicious diagram could trigger the extension to fetch a resource from a potentially untrusted resource. What are your thoughts on that?

• No need to make a vscode plugin just for a template library.

Actually, I think I generally prefer a proper extension model over urls. VS Code extensions are versionized, users need to opt-in (although you can configure your workspace to suggest certain extensions), they are discoverable, have a rating, a point of contact and so on.

Having said that, I can fix the draw.io behavior by just downloading the content behind the url in the extension rather than letting draw.io download it.

• No static template files in repos with the diagrams (imagine trying to version control that for a widely used template library)
• No need to add more libraries to the upstream drawio project

Can you elaborate on that?

[jgroom33]

I also don't like that a malicious diagram could trigger the extension to fetch a resource from a potentially untrusted resource. What are your thoughts on that?

I don't think the diagrams hold the url param. It is stored in the vscode settings.json.

• No need to make a vscode plugin just for a template library.

Actually, I think I generally prefer a proper extension model over urls. VS Code extensions are versionized, users need to opt-in (although you can configure your workspace to suggest certain extensions), they are discoverable, have a rating, a point of contact and so on.

The extension model is specified.

Having said that, I can fix the draw.io behavior by just downloading the content behind the url in the extension rather than letting draw.io download it.

• No static template files in repos with the diagrams (imagine trying to version control that for a widely used template library)
• No need to add more libraries to the upstream drawio project

Can you elaborate on that?

drawio has templates stored here ... contributing to this requires a high level of standardization. As an example, I work for a company with ~5k employees. We have custom visio templates for our products. It would be nice if those templates could be shared easily, but it's probably not worth adding all those to the drawio upstream. We're too small and niche.

The simpler approach is to have a github repo that has a single file (the template xml) and share that url. This becomes the extension methodology you mention above.

[gidduhome]

Hi, May I know if this item is ready or still in backlog?

[hediet]

Still backlog.