A Redundant Question on Tiddler Renaming

#1

This is an old age question and we had some good discussions in the Google Forum and GitHub.

  • Using state, temp and data tiddlers to keep information for configs, setting, status, comments, … is quite common in Tiddlywiki
  • These states act like permanent storages from session to session
  • Some states, or in better language sub tiddlers keep data important to main or source (or parent) tiddler
  • Sub tiddlers, normally created automatically/programmatically and are based on parent tiddler title like : $:/state/$(currentTiddler)$ or Comment by '(anonymous)' on '$(currentTiddler)$'

When you rename the parent (source) tiddler you loose all these connections for example for Official Comments Plugin, for Shiraz dynamic table with summary and footer calculations, for kookma Todolist, …

Relink is a revolutionary plugin helps to reconnect tiddlers together again!

I want to know what is the best practice to address this issue?

Does Relink from @Flibbles can be used to address this issue?

Note that, here you normally need a sub tiddler title to use it programmatically, not manually!

#2

Some suggestion:

Relink can handle automatic renaming in fields! So, one solution my be:

  • to use a parent field in all subtiddler
  • freely create sub tiddler with some prefix+timestamp
  • on rename subtiddler wikk keep their name
  • on rename Relink plugin will update the names in parent field
  • all users can access the name by some script
    • search all tiddlers have a parent field
    • check if parent value is the equal to current tiddler title
    • use it

This is working solution but it is slow, every time you need to search and find the sub tiddler. This will be time consuming for a big wiki with many tiddlers!

#3

Relink-titles is designed to be a solution for this, but everyone thinks it’s just for directory structures.

Relink-titles accepts tiny modules which designate rules for how to relink other tiddler titles based on the current rename occurring. There’s an example module here, but looking at it, it’s kind of daunting how large it is, even though 95% of it is comments. It may be time to create a new built in rule sometime.

4 Likes
#4

That’s far from a redundant question.

I take this approach…

I have a simple macro that prints a small, circular button which I float:right in tiddlers. The button is only visible when a global master switch is turned on, “Dev Features”.

The macro takes a single arg which links to a tiddler. Typically, a subtiddler or supporting data/config tiddler used by the host tiddler.

The host tiddler(s) can be anything of course. Sometimes a host can have more than one little circle button:

image

A tooltip lets me know what tiddler is linked:

image

The approach is this:

  1. Plan ahead
  2. No need to search
  3. (and if I do end up searching, add another little circle) :upside_down_face:
#5

We have all these problems and concerns because TW breaks the fundamental principles of database design. Database design principles go back at least to the 1970s, and researcher E.F. Codd.

In TW, the same field is used for title and for tiddler identification. It’s also used for “hidden” setting and for “tree” structures. This is fundamentally a flaw. It’s great that we’re able to work around it, but it’s still a flaw.

Oh well, all software has flaws. I think it might be a computer extension of the Godel theorem.

If tiddlers and tiddler links were based on an internal id, renaming wouldn’t be so problematic. You could rename a title anything you wanted without causing problems. It’s likely almost all the other info systems you can think of with more than a thousand users use an internal id for tracking notes.

It’s great that we have the Relink plugin, but I don’t like having to depend on a 3rd party tool for an essential service.

Anyway, another way around the renaming problem is to not rename tiddlers. Give tiddlers the best informative title you can. Then use uni-link and aliases to create your links.

Another approach is to give the best title you can, rarely change titles, and then use tags as your main organizational tool rather than links. When you change titles, tags are automatically updated.

You could, in a worse case scenario, assign a unique tag to every tiddler that you want to link to. Then when you link use a {{{}}} filter transclusion to link to that tiddler by tag id.

2 Likes
#6

I am wondering why core has not this unique id? Keep full backward compatibility, still when you click new tiddler button, or you use widgets to create a new tiddler, a hidden field can be created and store this id! ancient plugins and tools all can work with TW having this new feature and new tools and plugin can benefit from it!

1 Like
#7

Thank you @Flibbles I am experimenting with Relink-title! I did not quite understand if I need to update the module for my own use case or not?

#8

As far as I can see it. The JS-module is an example for other plugin authors, to add a specific rule that will automagically work with the relink-plugin if it is installed.

So you shouldn’t need to mess with that.

#9

Gold. I’m expecting TWX to do just that.

For my “main” tiddlers, they get a uuid stored in a uuid field, a numeric title stored in the title field and a subtitle field for a friendly title. I have a set of macros that enable linking via either uuid or title fields (never the volatile subtitle field though the link shows the subtitle as it currently is).

Result: no link breakage.

#10

@pmario - so I need to customize it for Todolist plugin as an example!

#11

I don’t know Todolist. … but if the Relink-Titles is installed it would do this:

  1. I did add an “x” to the name.
  2. It will rename the state tiddler.

IMO that’s what you requested in the OP if I did understand it right.

grafik
grafik1606×909 40.5 KB

#12

@pmario is correct. You shouldn’t have to update relink-titles to add rules for it.

However, I think the “$:/prefix/myTiddler” pattern is common enough that it may be worth adding such a built-in rule to relink-titles, even if it’s deactivated by default.

#13

@Flibbles - does the module supports multiple rules at the same times!
For example

$:/keepstate/$(currentTiddler)$/task
$:/keepstate/$(currentTiddler)$/done
$:/comments/$(currentTiddler)$
$:/comments/$(currentTab)$/$(currentTiddler)$
#14

That’s correct! there are many cases as “$:/prefix/myTiddler” where prefix may change from plugin to plugin!

#15

That’s right Mario! of course in the real case there are different type of title! but most of them as explained by @Flibbles is like $:/prefix/$(currentTiddler)$ of course the part $:/prefix may be $:/prefix1/prefix2/$(currentTiddler)$

#16

@Mohammad The idea was that you could add a rule which would handle whatever prefixes you want, or however many. But if I find the time in a few days, maybe I’ll add that inbuilt rule.

The problem is, while you can make a rule specific to your use case, my inbuilt rule would need to be generic and configurable not only by end-users, but by other plugins which have their own prefixes to register. I never did think of a good schema to cover all that.

#17

Thank you @Flibbles
I go to create my own module based on the example provided!

By the way, I would be happy to experiment with the new version!
This will resolve the big issue of keep subtiddler connected when they are produced dynamically (programmatically)!

#18

@Flibbles wondered if additional items could be added by a tag, so each plugin can include a rule in a tiddler with the magic tag. I must say Relink should be in the core plugins if not in the core.

Certainly to have relink handling the idea of tiddler names spaces through prefixes, though this is already normally the case would be marvellous, perhaps even permitting a user interface to give designers the opportunity to surface some user optional relinking. For example archiving tiddlers by relinking and allowing new tiddler with the original names to make sense or a track and trace renaming activity for an audit log or even undo or redo or replay features. Re-link need only provision the tools for such advanced features with others introducing their code and rename rules.

@Mark_S without going into the technical argument I can not concur with your belief in the limitations of the titles and database rules. To me it is simple to use conventions or prefixes to effectively define multiple database tables in tiddlywiki, maintaining the unique tiddlers keeps everything effectively in one meta table which means it is a sort of universal database.

I have raised the desire to give the concept of automatic titles a go so as to use a compound tiddler model to represent different tables. I think this would help reduce this perception of title limitations.

Also better than GUIDS I have built methods to give any tiddler a TSN unique Tiddler Serial Number, even address cross wiki transfers, however I discovered the Globally unique Ideas can be bypassed in most cases if you insert some facilities in the import an export processes, basically prefix the imported set of tiddlers when and if needed. What was interesting to discover only a subset of circumstances demand TSN’s so a subset of tiddlers can have them. You could possibly leverage the caption or alias plugin “uni-link” of Mario’s as well.

An example of a more than adequate work around is Streams, it creates subtiddlers based on a tiddler title and time stamp, I don’t like them appearing in recent tiddlers so I configured the tiddler naming value to use $:/stream/tiddlers/unique time stamp. So all my stream items for different tiddlers exist under this naming standard and can only be seen from the stream master tiddler, yet I can programaticaly extract them and rename the subtiddlers to regular tiddler titles so they are promoted to full tiddlership (another tiddlywiki word coined?), yet with relink the happily stat in the stream. Basically once creating a relationships within a stream tiddler the child parent relationship I can use any database model I want but tiddlywiki will always remain a single database.

Where I look forward to a lot of fun one day is rather than predictive text the idea of predictive naming. Going beyond new here (with tag) the idea that new tiddler titles could be determined (semi-automatically) from context, relationships and values. Interestingly in many cases a new tiddler or subtiddler title may be sufficient with just the default increment eg; “Parent tiddler task N” or “Parent tiddler child N” with the caption being their name if it were a duplicate. Despite disagreeing (perhaps unnecessarily) I value your (@Mark_S) well informed view point.

#19

This would tie it to the TW release cycle, which is much slower than 3rd party plugins, which are independent.

2 Likes
#20

TiddlyWiki is not a database. … Technically it’s a javascript object store.

TiddlyWiki users don’t know the “fundamental principles of database design” and they shouldn’t have to. Users want to access tiddlers by “human readable” names. … Everything else increases complexity.

I think it’s a different concept, that allows “non programmers”, to create crazy stuff, based on wikitext.

I did create a post at GitHub Discussions How the TW internal data structure looks like and why data-tiddlers are not optimal · Discussion #6116 · Jermolene/TiddlyWiki5 · GitHub where I give a short overview about the internal storage structure in TWs core.

TiddlyWiki data store is optimized for “fastest possible access to a tiddler title” that can be reached with javascript. See point 6) for “why tiddler titles have to be unique” and “why every other structure would be slower”.

1 Like