I’m facing a challenge. I want to use Obsidian as a documentation manager for my project. The problem is we use Azure DevOps wiki, and we want to access our documentation from ADO.
Basically, ADO simply shows md files.
The problem is, I want to use some plugin, for exemple the plantuml one. When I declare a graph, I use a declaration like this
```plantuml
A-->B
B--> C
The Graph is rendered as an image, after a call to plantuml rendering api.
So : I would something to generate a kind of render of my files. Preserving the code to update but show the saved image as default.
We have the case for a lot of plugins (code, timeline, …). is it possible ?
This is a more generic version of persisting a dataview query to allow for links to become listed in backlinks and what not. The keyword is that you want the output of whatever plugin you’re using persisted into the output. If you had something like this going, you’d have both the source to generate the figure in a commented version, and the actual output of it.
I do not know of any plugins currently capable of doing that using only the markdown text and supporting many plugins, and not sure how easy it would be to do for a general solution.
However, there exists tools which are capable of exporting to html, which I reckon could be transformed back to markdown using some other tool. So maybe look into plugins like Share note, Markdown export, or HTML Export , you need one which uses the reading mode output as its input to produce the markdown you’ll need to be included as documentation.
Thank you for the answer, I think you understood well what I need.
I will check these plugins ; Maybe I could use the code to create a dedicated plugin. I’m little bit afraid I cant use this kind of work without Obsidian opened (with a cli). And this is a problem to bring it into a cicd pipeline.
First concrete problem of using a proprietary system… The open format of the notes is not an argument anymore when we use plugins => The sources are partially locked into a proprietary software
It’s a challenge to use stuff unique to Obsidian, yes, but if you persist correctly, it shouldn’t be an issue to use in other systems as long as the markdown is complete.
Let us review three examples:
## Alternative 1: The query
```dataview
LIST LIMIT 10
```
## Alternative 2: With local persistent query
<!-- query-begin
LIST LIMIT 10 -->
<!-- query result -->
- [[file 1]]
- [[file 2]]
...
- [[file 10]]
<!-- query end -->
## Alternative 3: With remote persistent query
<!-- query-begin: a1b2c3 -->
- [[file 1]]
- [[file 2]]
...
- [[file 10]]
<!-- query-end: a1b2c3 -->
The first alternative would only work in Obsidian since it’s just the query, and will list the intent in another markdown capable system. The two other alternatives will present the query result, since it’s persisted, and they differ in the matter that Alt 2 keeps the query used within the note itself, but Alt 3 just keeps an ID of the query. The query would then need to be stored somewhere else within your vault.
Doing it this way would allow for any other markdown capable system to display the correct result, without the ability to update it. Obsidian, given a plugin handling it, would be able to update the query result when you want it to do so. This could possibly be automatic, or by triggering a command through a button or hotkey or similar.
The advantage of Alt 2 in these circumstances would be that it gives a hint on why the data is as is. Which when read by humans most likely would make some sense, at least with a better query than my whimsical example of just listing 10 files…
Wow, the soluce is amazing ! I love the second query.
I would object that the query itself is not enough to run the query => MD reader won’t have a Dataview plugin, and so the query is “dead” after that.
BUT, this solution (2) is perfect for me because the main need is to call plant uml server, wich is public api. What I love is the fact we can edit the query in another editor and the result will update when opened in Obsidian.
But I guess all of that doesn’t exist ? I should create a plugin for it. I have to think about the implementation, maybe the easiest way to do is to create note for the result, containing the ```dataview/* tag and tghe query updated to the latest version. After that we need a way to generate the view and store it. Maybe you have ideas ? For plantuml it’s easy because it’s just a picture, but for dataview we should get the md generated by the plugin… I don’t know how.
Last question is : will I make it, the project needs it soon, I don’t know if I can really propose Obsidian + a custom md plugin…
I’ve done some early coding to do this, and my thought for implementing this (and my focus has been dataview queries) has been to do the following:
Build a query within Obisidian as normal
Select this query (and/or copy to clipboard)
Trigger a Templater template to transform the query into a persistent query, and replace the original query with the commented version of the query and the query result
Have another template being able to recognise these kind of persistent query, extract the query, re-run it and replace the result part with the new result
The same kind of logic should be able to be used for other plugins using codeblocks or similar to generate some output, as long as they’re available to build their output through their API. You’d need to insert some kind of plugin-identifier into the query-id, but that shouldn’t be a problem. It’s hard to make it general though, so I’d start of recognising a few major plugins from your use case.
So in theory no need to create a separate plugin, but you do need to make some templates which do some file manipulation stuff.
HeHe… That’s always a good question, which nobody but you can answer. I’ve been thinking about this for at least half a year, and I’ve not come around to fully implement it. I just have a partially working solution, which is not very foolproof in any way, and nowhere ready to be made public.
I saw a solution using templater for dataview. The templater script call a “dv” object (to call dataview api).
Problem with this solution is… It will work only with Dataview.
I think we can generalize it by getting the render html of the block. The blocks are names “block-language-*” in the rendered page. For example : block-language-dataview, or block-language-plantuml.
So imo the plugin solution would be better. I “just” have to find the solution to get the rendered view of the page. Maybe the obsidian API has the option ?
If you opt for using the rendered version, then you can’t transform any of the files to a markdown related engine later on, unless that supports html rendering. You’ll also then need to maintain a double set of files, one with the markdown used to produce the rendered version, and the rendered version. But sure enough, you can go down that path if you like to.
I was just browsing through some plugins, and it turns out that the Run plugin, almost exactly does what we’ve been talking about here. It would allow for expressions or code to be executed from a “Run” block, and it outputs the result directly afterwards. And it provides easy access to at least Dataview and Templater plugins, through dv and tp.
