A Redundant Question on Tiddler Renaming

#21

I am a big fan of UUIDs Universal Unique IDentifiers. Back in TiddlySpace days, I did experiment with different ways to create a UUIDs

The links in the “TiddlyWeb ID generator” tiddler are clickable and create different version of IDs. … The last one is “UUID RFC4122”

They are nice and universally usable. But they need a lot more code in the TW core and UI to be used properly.

See the continent tiddler.

Example 1 uses a UUID structure which is nice for machines but the pure horror for humans (except programmers ;).

Example 2 and 3 use a simple tag-based structure, which is understandable and usable by humans “out of the box”. … It uses the “TiddlyWiki Way”

Thinking about it again and again, I did come up with the uni-link plugin and aliases. Alias-links can show any filed value as link-text. eg: [[alias-name|?my-field]] will show the text in my-filed as the link text. There are some shortcuts for caption, subtitle, title.

The goal was to create a mechanism to link with human readable “aliases”, without the need to rename tiddler titles. … So I could use UUIDs as tiddler titles and create a database. …

BUT why should I? The same things can be achieved with human readable titles, aliases and a streams-like outlining mechanism. … At least for my usecases :wink:

#22

Just want to say that I just read through your post and that was VERY helpful for me to understand - very well explained! I am a big fan of the title-based storage myself for the reasons you lay out.

I still find that the “performance game” is sometimes more about moving the bottleneck somewhere less impactful rather than eliminating it. I only point that out because I have a few use-cases where data-tiddlers, despite not being optimized make the experience of my wiki much faster in practice. Such as just having a whole company directory (20,000+ people) in a single giant system tiddler. Not only is it a large benefit from a file space standpoint, but it stays out of the way of the search area, filters etc.

And since it was mentioned, I’m also very pro-include (at least part of) Relink into the core. I understand your mention of release cycles and that’s totally valid, but to me part of Relink finishes the job that the built-in renaming mechanism starts. There are probably a lot of bells and whistles from Relink that are fine with being extra (and therefore part of plugins per general philosophy), but just getting the core to go a bit further than the tags and list fields seems like a no-brainer. Maybe it’s less controversial to suggest extending the core renaming mechanism rather than merging in all of Relink.

2 Likes
#23

No. Separating the title from the id is really, really basic. It isn’t rocket science. Using one field for two things creates endless problems.

It’s like saying that cooks don’t want to know the difference between petrol and water, so they should be allowed to use either in cooking.

#24

Sorry, can’t let this slide…

What does a database have that the TiddlyWiki store doesn’t have, that prevents it from being viewed as a database? Or, in general, when is a data store not a database?

Now that we’ve moved from DIV storage to JSON storage, I’d posit the store is JSON objects1 – which is tantamount to saying it’s language agnostic (these days). And under node.js, it’s not hard to imagine a query language (even SQL, God forbid) with a suitable translation layer, being used to present a CRUD UI for records (tiddlers) stored in JSON and/or .tid files. It would even be possible to implement something similar on top of a flat-file TW (note: I’m talking about being possible, regardless of whether it is likely or even necessary, let alone warranted).

I think there’s a particular prism through which “we” view TW. Sometimes it’s worth shattering the prism.

$0.02

[1] I assume, anyway. I’m not that familiar with the core.

2 Likes
#25

Good on ya. Right on the mark.

That said, TiddlyWiki was designed as-is for a reason, maybe some wiki-ish habit from wiki forefathers …

In my previous career documenting my workplan/tasks for the system I supported, maintained end-user documentation and I.T. support documentation (development, help desk, operational support …), I relied heavily on a wiki called ProjectForum (odd-ball name for a great, but now defunct, wiki built with tk/tcl, storing content in flat-files, and having a built-in web server … awesome little product.)

Anyway, it did as you mention (i.e. a unique key generated by the wiki, in the background.) A user would type in a page name, and create links on pages with square brackets (ex.: [[Page Name]]), but the actual URL’s for links would have the unique ID.

So changing page names would never break anything, ever. No link rot, ever.

A lot of folk, though, do not like links that are not human readable (i.e links that have a unique ID number that means nothing.) A lot of folk, I think, prefer the actual title of a tiddler/wiki-page to be in a link. I think that’s a bad idea that can be handled differently.

Anyhoo, long-winded way of me saying that you are preaching to a like-minded choir. (May be just me, and I can’t sing without birds falling from the sky…)

#26

Yea, In different places I wrote, that there are usecases where data-tiddlers are a big PRO. Yours probably is one. That’s why it’s so hard to eliminate them. … We need something better :wink:

1 Like
#27

+ 10 that

- 5 that

Probably not rocket science, but I’m guessing a tedious, if not hellish, and error-prone mess to rework and test.

#28

Yea, … I was a bit sloppy there – TW started 2010 we have to keep that in mind. Since 5.1.2x we definitely are applying mechanisms that come from databases. … What makes database access fast is “indexes”. … 2010 the devices haven’t been fast enough to do “server + client work”.

We did implement caches and indexes into the core for “backlinks”, “tags”, “fields”, “filters”. We also implemented a mechanism that makes it easier for plugin authors to create their own indexes.

… But still, using UUIDs would mean to create the whole UI from scratch and a big part of TW filters too. …

#29

@TW_Tones You can absolutely have other plugins introduce their own relink-titles rules. It wouldn’t use a tag system. It uses the relinktitlesrule module-type system.

As for the discussion about adding Relink to core, I’d be all right with that, but I completely understand why Jermolene doesn’t. Relink is hefty. And it’s solely my responsibility, so I keep it up to date. A core plugin would start getting muddled and slowed by other fingers.

Also, Relink isn’t technically a comprehensive renamer. There are scenarios where renames are impossible (and even realizing they’re impossible is impossible). They’re esoteric, but I’ve always felt that, as a 3rd party plugin, Relink is understood to be an unofficial attempt at renaming rather than the official “this never fails” solution.

But those are all weak reasons. I’d still be up for a merge. However, I’d hope whoever does it consults me, because there are several features that SHOULD ABSOLUTELY BE SCRAPPED. I’m mostly thinking about Relink’s complicated placeholdering system which I’m guessing 0.05% of users benefit from.

1 Like
#30

I’ve been thinking about this for a while. I’d love a “feather” version of relink that, upon change of a tiddler title, scans only for references of that tiddler title in [[]] and {{}} instances wherever they may be (in whatever field).

That’s it, that’s all.

Do you still have an older version of relink available that does just that?

All of the other goodies in there are pretty cool, but I like to travel light, so lean and mean feather-weight relink would hit the sweet spot for me.

#31

@Charlie_Veniot, unfortunately no. The early versions of Relink focused on filter fields and stuff like that. Also, they were buggy. The best I can recommend for you is to run Relink through my uglify plugin, which cuts its size down by half.

#32

I do like all this discussion about fundimentals it has many advantages. However i do feel sometimes when discussing concepts, fundimentals and especialy performance that we fail to address context and complexity levels.

What i mean is since tiddlywiki can be used in many contexts what constitutes its most complex feature varies. Since users or consumers vary, the issues vary and so to do performance issues.

Often the most chalenging part is communication with the user.