Virtual Page Templates

Ideas
1

Let me throw out another idea into the ether.

When I implemented tag pages (example), I realized: why would this need to be hardcoded in SilverBullet? Basically you can implement 90% of this using Page Templates you just don’t want those pages to actually be written to disk. They should just be… virtual.

Hence this idea of virtual pages. You’d define them much like page templates:

---
tags: template
hooks.virtualPage:
  forPrefix: "📌 "
---
{{#let @tag = replace(@page.name, /^📌 /, "")}}
# {{@tag}}
These are all objects in your space tagged with #{{@tag}}.

## Pages
{{#each { page where tags = @tag } }}
...
{{/each}}
etc. etc.
{{/let}}

Whenever you’d hit a link to any page starting with the prefix (so 📌 in this case), you’d get a template rendered, read-only page.

I like this, because I can eliminate the current tag page implementation using it, but I’m sure there’s other use cases as well.

One open question here is if forPrefix is a good way to match pages, or it should support e.g. arbitrary page name patterns, e.g. using regexes?

Thoughts?

3 Likes
2

I am not sure I understand one thing. Let me see if i can explain myself:

tag pages are created on demand, right? no matter what #tag the user would create.

Would this replacement with Virtual Pages need that you create in advance a virtual page for every prefix you’d like to use?

If so, wouldn’t we lose flexibility?

3

Virtual pages would also be created on demand. So indeed, whenever you’d access a page starting with the forPrefix prefix, it’d be rendered using this virtual page template.

In another thread we discussed generating a weekly overview. You could reserve the Weekly Overview/ prefix for a virtual page template, which would based on whatever you put after Weekly Overview/ would generate an overview for that particular week.

I hope that makes some sense.

4

Aha, I see.
Yes, makes sense and another powerful feature :smiley:

5

I was just thinking that would be a great thing to be able to define for my setup. I’m all for it.

1 Like
6

Rather than forPrefix:, you could use startsWith: to probably more closely match what is happening internally. You could additionally or alternatively have endsWith: to further narrow down the match. The presence of both would be AND’ed together.

1 Like
7

I really like this idea. What about using a “route parser” like GitHub - philipnilsson/teki: Teki - The unreasonably efficient TypeScript route parser ?

This would also give the benefit of parsing out the parameters automatically as well.

8

I agree, startsWith is a better more clear name.

As for regexes as matcher I would try to stay away from them in this case. I think it is better to force the consistency of all pages starting with X.

9

There’s some other places that use forPrefix now, but I can deprecate that and suggest using startsWith instead. Seems like a better name, and naming things is hard.

4 Likes