Confused with conventions: Library/Personal vs /template... or `Page Template` and `template`

General
1

I’m trying to make sense of the naming structure and conventions used in Silverbullet and I am having some confusions around them. For example, looking at these 2 files:

  • Library/Core/New Page/Page Template.md
---
description: Define a new Page Template
tags: template
hooks.newPage:
  suggestedName: Library/Personal/Page/
  forPrefix: Library/Personal/Page/
  confirmName: true
frontmatter: |
  tags: template
  displayName: "|^|"
  hooks.newPage:
    suggestedName: Library/Personal/Page/
---
  • Library/Core/New Page/Template.md
---
tags: template
description: Define a new template
hooks.newPage:
  suggestedName: template/
  forPrefix: template/
frontmatter:
  tags: template
---
|^|

  • When should i use each one of them?
    They both seem to create a new template page.

  • With Page Template.md the folder Library/Personal/Page is introduced. Why this new location?
    Is there a valid reason to separate template pages from Library/Personal/Page ones?

2

Honestly, I forgot about the template related page templates I created earlier and should probably delete them until we figure out the following:

What would be a good naming convention for custom templates?

For libraries I settled on: Library/name/template type/template name but where would we suggest to keep your own custom ones? Also under Library? Somewhere else? What would be a good convention? Once that’s decided we can probably encode it in template templates again.

Thoughts? Ideas? This is uncharted territory.

3

I think that Library could work for hosting personal content too, so I am ok with developing that idea.

Anything like:

  • Library/custom/[phd|pkms|catalog…etc]
  • Library/personal/[phd|pkms|catalog…etc]

Based on SilverBullet, the idea is to offer more libraries in the future, right?
If we all use Library to host our own custom templates/snippets/etc, maybe we could easily share them in the future too.

4

Yeah I was thinking in the same direction. Some sub folder of Library makes sense. And indeed the idea is that more libraries (ideally community contributed) would come later.

5

Ok for 0.6.0, I removed these template page templates until we settle on best practices. Since generally library imports are a one-off thing I don’t want dump too much trash into people’s spaces from day 1.

6

Thanks Zef,
I updated to 0.6.0 but i still have them.
Is there a way to clean them automatically or only manually comparing with a clean instance?

7

They’re just pages in your space. Just delete them with Page: Delete or from disk directly.

This does bring up the topic of somehow keeping libraries in sync, while also allowing people to edit.

8

Yes, exactly.
At the end i did a 1:1 comparison and cleaned my instance.

I guess a diff tool is out of scope of SB so, not an easy problem to solve :slight_smile:
In the meantime, it is not that much work doing it manually

9

I’m open to ideas here. Technically if you just want to keep things in sync without allowing yourself to edit templates, you can already use federation and put this in your SETTINGS:

federate:
- uri: silverbullet.md/Library/Core/

instead of using the Library Import path (you probably shouldn’t do both, because you’d get everything duplicated).

But I think people may want to tweak these templates for their own use, that’s why I went with the “just copy the things” for now.

I now see that I have to update the federation page with some more up-to-date examples.

10

I do prefer the Library import path instead of federation.
Indeed I removed federation with 0.6.0

The first thing i did was modify Table of Contents so, happy i have the opportunity to do so.

As for ideas, difficult to come up with the right process. it is like implementing git and diff tools here.

some random thoughts:

  • Library import should import files but never replace the ones that have been modified by user.
    This means it would pull new ones and update current ones, only if current ones were not modified by user.
    So basically it would take care of: upgrading and pulling new files

  • If user modified files, do not touch them

  • Maintenance page (or a new one) could be used to show through a query the diff, so the user can act on it

1 Like