How to organise tiddlers: when to put them in the 'system' space and where?

#1

As I am trying to create more sophisticated content, I would like to know if there is a best practices guide to name my tiddlers. More specifically:

  1. I am creating event tiddlers that I will only view and edit directly in an history tiddler where they are transcluded. So I don’t want to see in the river nor in the recent list.

  2. I will also have data tiddlers with a similar use.

So, should I put them with System tiddlers by giving them name starting by “$:”? (I have already put some templates here). Any advice?

#2

If they should not show up in the recent tab, they have to be system-tiddlers. That’s what they where created for.

As you found out already, it will be important for yourself to give them the right names.

Finding the right names is difficult and may need several iterations. … Sometimes the “first” name turns out to be wrong. So you will need to prepare some renaming “sessions” …

For example we used the $:/tags/… namespace for system-tags. … So everyone knows what those tiddlers are used for.

If you need $:/state/.. tiddlers, you will need to go with that prefix, since those state tiddlers are not synced back to a server-backend, if that’s important for your… … If not, just ignore it

I personally add my own prefix, if I need more system tiddlers eg: $:/wl/something … where wl/ stands for “WikiLabs” … so I can avoid name clashes with other users that may want to use the same name.

We call prefixes like $:/wl/... namespaces. So I did create my wikilabs namespace and then I can be pretty sure that they won’t clash with other users stuff.

In general you should name your tiddlers about “what they do” and not what they are. eg: $:/xx/integer/value … does not make much sense. … $:/xx/lineHeight … does.

Or $:/xx/config/lineHeight … indicates a configuration value, which will probably have an edit-text dialogue somewhere.

$:/state/xx/ … may be a tiddlers used to remember UI states
$:/temp/xx/ … are “throw away” variables that may be freely overwritten. Important never ever rely on “temp” variables!

From your examples you will probably have $:/xx/date/.. and $:/xx/event/.. namespaces.

Hope that helps
-mario

4 Likes
#3

Thx @pmario, this is helpful. I was leaning towards this solution and you just confirm this is the right way, so let’s go for a renaming party.

About $:/state/xx/, I have created a field mode for each event tiddler to know if I have to display their view template or their edit template. Maybe should I have manage this state with a $:/state/xx/ or $:/temp/xx/ tiddler?

#4

For single file wikis the $:/core/save/all tiddler is responsible what is saved. As you can see, the $:/temp/ tiddlers are excluded from the save filter. The $:/state/ tiddlers are saved.

So it depends, if you want to have them back after a save and reload

As I wrote $:/state/ tiddlers are not synced to a server. see: $:/config/SyncFilter, which is the “sync-filter”

1 Like
#5

If you don’t mind me derailing the discussion for one quick question- which tiddler handles what is recognized as a system tiddler?

Would it be possible to have the same behavior applied to another prefix, something like ¢:/ ?

Also, returning back to the topic, Whenever I wanted reference on what to name my own system tiddlers, I always looked to the explorer tab in the more tab of the sidebar, and if I couldn’t find a sufficient answer there, usually someone’s plugin had the answer.

2 Likes
#6

Yes. IMO that’s a good way to get some inspiration. … Plugins usually have longer names, since the should go with $:/plugin/<author>/<plugin-name>/<tiddler-title> …

So the <author> field will replace the xx in my examples but the tiddler title will probably still have more “namespace levels” … But imo it’s also true, that there are usually several iterations until the names work out and are maintainable. I usually find out if my names work if I read the source code after 6 months and it still make sense. … If not … :confused:

2 Likes
#7

Out of the box it’s $:/ only. It’s hardcoded all over the places. … But eg the timeline macro can be called with a subfilter (which imo should be deprecated) like so:

<<timeline limit:10 subfilter:"!prefix[¢:/]">>

So you would need to add a lot of exceptions to existing UI filters. But it should be doable.

As I wrote the subfilter as it is used for the timeline macro should be deprecated, because we do have much better mechanisms now. … Many of the super old macros which use $text-substitution$ need to be rewritten.

They have a lot of disadvantages. … But we need a new text-substitution function first.

#8

In point of fact, that’s not entirely true. There’s just one JavaScript function that is used to test for system tiddlers:

So, it would be a fairly straightforward hack to extend TW to treat ¢:/ the same as $:/, but that’s not something that there are any plans to support directly in the core.

1 Like
#9

Yea, but is[system] and !is[system] is used all over the places. … So from my point of view all those elements would need to be modified.

I did understand the question as: If ¢:/ could be used similarly to the system-prefix.

IMO it would make absolutely no sense, that it does the exact same thing. It would be redundant and confusing.

#10

The reason I chose to use ¢:/ is because in my TiddlyWiki, the ¢ was a quick way for me to denote ¢ustom copies of system tiddlers, ones that I had modified to do things I wanted to test, just for elaboration. I was just curious if there was a method to do so.

#11

That’s what I do. I put my PDF, audio, video, docx tiddlers into system folder. These tiddlers have no value or meaning out of the context. For example, my plane ticket PDF makes more sense inside a tiddler that has all my trip plans.

I prefix these tiddlers title with $:/talha131/files/, like $:/talha131/files/pdf/ for PDF tiddlers. This way they all appear neatly under pdf/doc/audio/video folders in the Explorer tab.

Consistent prefix also means I can easily export them all.

2 Likes
#12

I support the use of the name in tiddler titles in the discussion above $:/xx and $:/plugin/xx/… especially for what we could call distributable tiddlers, those we may want to move between wikis.

  • In full however we use $:/xx/projectname/tiddlername and $:/plugin/xx/projectname/tiddlername
  • The projectname would be something like “pallet switcher” or “Split-path” etc…

However something to keep in mind is the use of a full namespace is not needed, for example with state or temp tiddlers just making the current tiddler title part of the name, or using the qualify macro is sufficient.

  • Eg $:/state/projectname/current tiddlername
  • Since the tiddlername is unique by definition then the state/temp tiddler will be unique in the wiki
  • If the same projectname was used by two projects most users will notice while installing the project name and be alerted to potential conflicts
    • personal experience making solutions clashes are still remote especially if the brand/owner/publisher is used the xx.
    • FYI I use PSaT which stands for “People, Systems and Things”
1 Like
#13

You use the namespace in a nice way! Which makes this very useful both on Node.JS and single .html wiki.