Advice on complex delete scenario

How would you go about performing a delete that should cascade to other deletes?

I’ve been building a wiki for a local political party. If the (non TW-savvy) administrator with edit rights chooses the delete button for person Fred Flintstone, this should also cause the deletion of related tiddlers:

  • Membership/123: ({name: 'Fred Flintstone', organization: 'Bedrock Zoning Board', position: 'Vice-chair', term: '2021-2025'...}
  • Membership/456: ({name: 'Fred Flintstone', organization: 'Dinosaur Party Committee', ...}),
  • Candidacy/789: ({name: 'Fred Flintstone', organization: 'Board of Selectmen', party: 'Dinosaurs', contest: '2023 General Election', ...}), and
  • LawnSign/555: ({organization: 'Board of Selectmen', names: '[[Betty Rubble]] [[Fred Flintstone]]', ....}).

I can probably do the logic to find all the things that have to follow, and at this point they will probably not cascade to a second level (maybe later!). The trouble is that I want a confirmation dialog that this additional data will be deleted as well. The only mechanism that I know of for that is the ActionConfirmWidget, but that wants its message up front. I expect to have a page with lists of parties, people, organizations, memberships, candidacies, lawn signs, and so on, with add buttons for each group, and delete and edit buttons for the individual parties, people, organizations, etc – hundreds of items altogether. And I don’t want to pre-calculate the deletion message necessary for the action widget for every one of these. I would like to do it in real time once the delete button is pressed.

The data is reasonably well normalized, with many tags serving as de facto database table names, some of which simply mediate many-to-many relationships between other tables. (Like Membership and Candidacy) I’d like to not leave dangling references to dead data. That’s why I would like this approach rather than the more manual and tedious one of deleting Fred’s memberships, candidacies, lawn signs, and whatnot before deleting Fred; that’s sure to be done incorrectly.

Has anyone done something like this? Any advice on how to get this to work? Advice for an alternate way to do this altogether? Any other suggestions?

You could use a filtered attribute to assign the message to $action-confirm and have the filter calculate the message. Alternatively, use a text reference for the message and update the tiddler the text reference points to with the appropriate message (using $action-setfield) before the $action-confirm widget. Do remember to set the tv-action-refresh-policy variable to always, and do not place the actions inside the button widgets. If that doesn’t quite meet your needs, perhaps some pseudocode that shows the desired behaviour would be helpful.

I’m not sure what that means, but I’ll look into it.

I’m not sure what “before” means here. Earlier in the source code (or at least in rendering order)? Or is it temporal? I have yet to actually use the ActionConfirmMessage, but it looks to me as though I would have to have the message established when I render the delete button. I’m hoping to delay that, and not do the complex filtering necessary to find all the cascades – which will then be used to create the message – until the button is clicked.

I don’t know what that is, but will look it up; it sounds promising!

Oh, is that a performance problem? I haven’t done very much with any buttons, and haven’t caught onto the tricks yet. I will look into this too.

Thank you very much. I’ll go look into this stuff and report back when I’ve absorbed it!

If you use the actions attribute of the $button widget to assign the actions to be invoked on click, rather than placing them in the body of the $button widget, they are only parsed when the button is clicked. As such any complex calculations can be delayed until the button is clicked.

Here is an example, albeit one that uses a static message:

1 Like

Oh, that sounds like it would solve my problem straightforwardly!

Lots of work to do, but this makes it sound possible. Thank you very much!