Better tiddler relation handling question

#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.

#21

Your topic is about improving relation handling.

And all of the issues you are bringing up, regarding TiddlyWiki’s relation handling, are all related to data integrity, a database management concept, and handling relations for data integrity is in the DNA of any DBMS.

My understanding by all I’ve read: you want your plugin to handle things that any DBMS handles naturally.

If that’s not what you want to accomplish, then this entire thread of conversation is giving some really easy to misinterpret cues. Might be a good idea to clarify what you are trying to accomplish.

Or, maybe everybody but me gets what you are trying to accomplish, in which case don’t be wasting your time with me. Much easier for me to withdraw. No worries.

#22

Ah, okay. I understood what you wrote as me trying to use TW as an actual database and backend for something else.

So yes, I am trying to accomplishing accomplishing better data integrity via JS and…

I am not even sure what and. I made this thread because I was really curious when @TW_Tones said:

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.

Because I thought there is some feature built into TW that I haven’t encountered yet which would accomplish what I do with JS without doing JS but then this all spiralled out of control with people feeling like I am attacking them by giving an example of something that stands in my way of expressing the models I want to express in TW and me feeling like people are hostile towards me because I want to do something probably barely anyone cares about ¯\_(ツ)_/¯.

So perhaps it’s just best to let this thread lay to rest as a testament to the ancient art of misunderstanding. I am fine doing what I do with JS and don’t think TW is somehow inferior for not having this functionalities, I learned a few new things (that imports can override existing tiddlers or that plugins can override core tiddlers) and probably made a few people’s day worse (including mine), for which I am sorry!