Better tiddler relation handling question

#1

Late edit: To avoid further confusion, I am thinking here from the point of view of developing plugins. The problems I mention with relationships can be solved if you’re building a standalone TW instance where you have full control over everything.

In TiddlyWiki as a modelling tool - let's discuss I mentioned some of the woes I have with handling relations and got two responses which I’d like to respond to to not derail the original thread:

PMario: I think the relink-plugin is able to handle that. It also gives you more possibilities to “show” relations in the tiddler (i)nfo area.
TW_Tones: Just add the relink plugin and configure your additional fields in it.

This unfortunately won’t work for plugins i publish as I don’t want to create a dependency,

I am on the road so cant give a full answer but I have solutions to all your pecieved problems with relationships. Could be a thread of its own.

I’d love to hear them!

If you provide your own buttons for tiddler creation, deletion and relationship assignment you can ensure referential integrity for any complex relationship.

Only if the user will use those buttons and I can’t really force them to do so always. They can opt to not use them or they can use an action to remove/rename things causing data integrity problems. And while I recognize it might be a very niche problem I’d rather foolproof things as properly as reasonable – and this falls under reasonable for me.

Adding titles to list fields containing spaces etc… can use the format operator and work if used the the right way.

I didn’t know about the format operator. While it is neat it exists it adds additional level of complexity as whatever you want to, say, append you first need to put into a variable and format it. It would be better for that operator to support treating the input as a single title.

(Which I know I could report as an issue but it feels like a waste of time – too small a problem with too much thinking required for anyone else to tackle.)

Pinging @pmario and @TW_Tones since I respond to both of you here :slight_smile:

1 Like
#2
  • Unless you include relink in your package you will have to reinvent the relink functionality in your package. You can pack it in your plugin.
  • you have more power than you think. Create custom button that looks like the core buttons and hide them, however if you design it well, they will just use your buttons to get what they want done.
  • you need to guide users and make it easy to do the right thing, and warn them if they do wrong.
  • I don’t think this is an issue, you desire a sophisticated solution and I am not sure you know how to do this with tiddlywiki YET, but will in time.

I am happy to help but at this point in time it is a big open question that would take me hours if not days of work to help you. We need to deal with a issue at a time I think.

#3

Let me list all the ways a tiddler can be renamed or removed that I am aware of:

  1. By clicking on “Delete” in the Tiddler’s header (may require clicking on “More Actions” first)
  2. By editing a tiddler, changing its name and saving the changes
  3. By sending message tm-rename-tiddler
  4. By sending message tm-delete-tiddler
  5. By invoking action <$action-deletetiddler/>

To the best of my knowledge there is no way to hide a button only on tiddlers that match certain criteria, so all I can do is use a custom Story Tiddler cascade to completely customize how the tiddler is displayed. This solves #1 albeit this is a solution that comes with one big caveat – you can’t really make it support different layouts.

Similar problem with #2 – I don’t think you can selectively change the UI to prevent editing the title so you need to use Story Tiddler cascade.

But #3, #4 and #5 can’t be solved at all without hooking into TW internals. And no amount of guiding the user to do the right thing will help here, because those why are fluent in tinkering or are learning can make a mistake and end up with cluttered list of tiddlers. And warning isn’t very effective, provided the user reads and understands the warning in the first place it still should be possible to put it where they will see it when needed.

I don’t think this is an issue, you desire a sophisticated solution and I am not sure you know how to do this with tiddlywiki YET, but will in time.

I think you misunderstood me. I meant that I could post a Github issue requesting improvement to append filter operator, not changes to handling relationships.

And I disagree that I “don’t know how to do it what I want with TW yet” – my complaint is that these things need to be done with Javascript and can’t be accomplished without it. And I am not really complaining either, I was commenting on this being a barrier to better expressing my models :slight_smile:.

#4

With all due respect I disagree with what I think you are saying, perhaps I misread you, perhaps you misread me, But the limits you see can be overcome and without javascript or core changes. If you look at the various read only setups you will see how what appears to the user can be fundamentally changed.

  • For example remove toolbar tags from buttons
  • Provide a different story tiddler cascade.
  • Create an alternative editor.
  • Modify buttons and add conditions
  • Remove the edit title part of edit tiddler view
    etc…

For a user to start using the following to bypass your restrictions it is best described as hacking;

  1. By sending message tm-rename-tiddler
  2. By sending message tm-delete-tiddler
  3. By invoking action <$action-deletetiddler/>

If as I think you are implying you want to prohibit totally such functionality, then I suggest you don’t use an open source, self documenting, uncompiled, software platform.

I am confident you can customise the environment to add additional relationship handling and referential integrity.

I cant afford too much more time, so please get more specific and we can address one issue at a time. If it helps add meaning to my words I have 10-15 years very active experience with TiddlyWiki.

#5

Many to many is a breeze in TiddlyWiki. A large reason why I like it so much. TiddlyWiki is ridiculously adept at handling extreme intertwingularity.

Without messing with javascript, and without touching anything in the core.

Can you give a domain example and the kinds of scenarios that cause you hiccups in TiddlyWiki ?

At worst, you may need to consider building an interface on top of TiddlyWiki to interact with and manage your tiddlers with rules. Like a custom delete button that will only allow one to delete a tiddler once other things have been done.

That said:

  • I’ve read very little from the other thread of discussion because it has quickly become way too long and way too busy.
  • And I’ve not read much here because the little bit I’ve read here is again way too long and too busy, and had pieces missing that must exist in the other thread.

If it helps, it might be worth creating a sandbox to play in via TiddlyHost.com

  • Edit/Add-on: I think that would be a terrific idea; we’ve all got varied experiences that might lead to very different approaches, and seeing them all might help you develop a unique solution.

(Refer to BASIC Anywhere Machine as an example of an interface on top of TiddlyWiki, and the Tifoist project as another example that in addition uses tiddler titles as the place for unique sequence number identifiers.)

1 Like
#6

@TW_Tones I think the misunderstanding might be that you’re thinking about creating a custom TW installation for a specific case, I am thinking about writing plugins that can be installed by anyone and minimising the risk they’ll mess things up somehow. In this context I:

  1. Can’t remove buttons from toolbar for a specific tiddler because it’s not supported in built-in layouts
  2. Can provide a different story tiddler cascade but it’s creates its own set of problems (duplicate code if I want those tiddlers to look the same, potentially not working well with alternate layouts, won’t follow updates to TW).
  3. Ditto for alternative editor
  4. Don’t think a plugin can overwrite built-in tiddlers and even if they can, it comes with another set of problems (similar to those from #2)
  5. Ditto for removing editing title

My bad I didn’t specify I am thinking about doing all of those things from the POV of a plugin.

I’d not call it hacking, those are tools I use almost daily with TW and while I suppose I might not fall under the umbrella of a casual user I am sure lots of people play with those. Or use various plugins and there is always a risk that another plugin does something weird.

Take my Task List plugin as an example. It has a single tiddler for the task list itself + whatever many tiddlers you create for each task. There are two situations where I had to resort to using JS:

  1. Renaming a Task List should update the reference to it in all Tasks that link to it
  2. Deleting a Task List should delete all the Tasks that link to it

#1 could be accomplished by using a tag but for whatever reason I really dislike doing so, or using field list instead of parent but I like the field names to be meaningful.
#2 requires JS

But then I am working on another plugin where for #1 I can’t use tags nor list field because I have a many-to-many relation and need to know which linked tiddler represents what and I’d rather not count on tag or list ordering to have that information (and that would seriously mess up/make impossible a lot of filters I use anyway).

Still, I wouldn’t say they cause me hiccups or a big problem – it’s just something I wish I could do without resorting to JS.

#7

You can setup a plugin that provides a specialized interface for things created with artefacts from your plugin.

Have your plugin create tiddlers that won’t necessarily be easy to manipulate the normal way.

The way to get your plugin-related things working in regular tiddlers: add a macro from the plugin in personal tiddlers.

Your macro inserts an interface into a regular tiddler that does the stuff a person would normally do the TiddlyWiki way, but now do within the boundaries of your plugin.

#8

Yes, this is what I’ve been doing. The problem is - tiddlers can still be removed or renamed deliberately or accidentally with actions, or by finding them in advanced search and opening directly (which can be protected against by using cascades and cuatom rendering of the whole tiddler if you want to go that far, though it may not look great with custom layouts). And I want to keep the data in a good state when that happens.

#9

First, don’t use tiddler titles to uniquely identify your tasks.

Use plugin-generated sequential numbers. Task 1, Task 2, Task 3 (Or T-1, T-2, T-3) etc.

Keep the name for the task list in a field (caption if you want). When that field gets changed, it does not matter because your tiddler titles never change. They are unique identifiers that always remain stable.

When deleting a task list, delete all the tasks linked to it first.

That’s easy. No javascript required.

#10

You can install plugins that overwrite tiddlers in the core plugin as long as it is the last, it will present the content in it instead.

I don’t know how to word it, or convince you otherwise, I think this is all possible except getting an “un hackable result”.

an experienced designer can address most possible issues but not all because the other plugin designer may take troublesome shortcuts. One way is to inhibit the installation of additional plugins, but you want to keep your own backdoor.

  • Good idea but that is taking on a lot, at some point you will need to trust the new user and they need to take responsibility for making changes that break things. You could help by publishing the mechanisms you use and tell them what not to do or what kind of thing “voids the warrantee”.
  • of course unless they can save they cant break your published copy.

So lets tackle a single item;

Just add in your plugin a modified copy of the core button to overwrite it. Remove the toolbar tag and even better wrap the button content with a conditional list widget, and or make your modified button obey the rules you want.

  • You can also use the css data to hide buttons
  • I am not sure why you refer to layout here but they too can be locked out.
1 Like
#11

You cannot protect the user from him/herself. It is his/her/their TiddlyWiki. They have full control over it. If that person wants to install other plugins that break your plugin, or delete tiddlers that break things, you can’t do anything about it.

You have to accept that.

TiddlyWiki is not like a back-end database over which the dba has full oversight, nor is it like the web application server over which whatever admin have oversight.

You can obfuscate, though. The tiddlers that are created via your plugin, make then system/shadow tiddlers.

1 Like
#12

If all task management tiddlers a user creates is via your interface, they will all have titles that are generated sequence numbers, and they will all be prefixed by $:/Maurycy/ (or whatever other unique “system tiddler” qualifier. And your plugin will have a clear warning to users must not touch anything in there, and a disclaimer to say that there are no warranties or guarantees, especially if the user monkeys around with anything that has that system tiddler qualifier.

If a user wants to create a personal tiddler and have it be part of your task management, then your plugin still generates a tiddler for task management. The ID of your tiddler, you create a field in the user’s personal tiddler that your plugin uses for linking. If user wants to rename the personal tiddler, sure. If user wants to delete that tiddler, fine. Maybe your task keeps just a little bit of metadata about the linked tiddler so that if it disappears, a user can still make sense of that task. Then maybe delete it. Or go “oh poop, I deleted that tiddler by mistake”: maybe the user can recreate that tiddler (via your plugin, which will recreate that tiddler with available metadata and setup the link again).

#13

Including the trash plugin and removing the delete button is another approach.

Once a lot of changes are made it is less a plugin, or set of plugins and more like an edition, but a whole edition could be embedded in a plugin if wanted.

#14

I think most of those actions have a tw-hook, that can be used by plugins to modify the core behaviour.

js hooks do stack. So there can be 2 plugins registering the same hook. It only needs to be done right.

#15

I feel like this conversation is starting to eat its own tail :slight_smile:.

Let me recontextualize things – I mentioned that making relations in TW is cumbersome in the context of this question in the thread I linked at the top:

What features in tiddlywiki help or hinder model making in tiddlywiki?
(emphasis mine)

I mentioned in there that the issues I talked about (keeping tiddlers in sync after renames and removing tiddlers when their related record is deleted) have to be solved by JS, while mentioning there is no good solution to do so without JS. I forgot to mention my question is in the context of plugins which also must’ve caused some confusion. Most of the suggestions mentioned I either already implement (Using hooks, prefixing my custom tiddlers with $:/, using cascade to replace how the tiddler renders) or mentioned myself and why they won’t work in my situation (hiding buttons, changing UI, using tags or list field, using a plugin).

I also disagree you can’t protect users from themselves – my way to look at this is that it’s my job as plugin developer to ensure that my customers don’t accidentally break stuff because they may not have the know-how required to fix it.

Sorry for the confusion.

But I think my complaint stands – vanilla TW has no way to easily manage foreign keys (to use SQL vocabulary). Which might make me a niche user, something I am totally fine with, but is the answer to the question posed in the original thread.

#16

Don’t forget drag and drop for importing a tiddler, to overwrite any tiddler created via your plugin, or in your plugin, or otherwise.

Trying to get TiddlyWiki to provide database server and web server controls, not sure TiddlyWiki is the right way to go if you require those.

Best of luck. If you come up with something, I look forward to seeing it.

#17

Thanks, I didn’t think of this one. Though I find this one to be above my level of paranoia I am very curious to check what will happen.

What makes you think this is what I am trying to accomplish?

#18

Also by $action-setfield you can rename

#19

Actually clone, the original tiddler will stay and a clone with the new name will be created (just double checked it). Though if you combine it with $action-deletetiddler…

#20

That’s quite true, you need to delete the original tiddler.