Better tiddler relation handling question

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

#23

Nah, TiddlyWiki doesn’t have a “data integrity” feature. TiddlyWiki does have everything needed to build the feature.

Natively. Maybe with some HTML and some CSS involved. Definitely not perfect, but good enough considering the DNA of wiki.

Javascript not needed. No need to override core tiddlers if, like me, you’d rather avoid that.

That makes me happy because I loath javascript. Javascript is a rare necessary evil for me only when it is impossible to do with TiddlyWiki: example, a random number generator, or doing some funky stuff with browser local/session storage.

But, when a person knows javascript and it is the quickest way from points A to B, I think that person is bonkers to not use the most effective way to get there (i.e. use what you know, in this case javascript), unless there is some benefit to go the javascript-less way.

For the last 1.5 years, I’ve done loads of experiments (much of it with focus on multi-user TiddlyWiki with just TiddlyWiki au natural) that, amalgamated, do the kind of stuff you’re talking about. Good luck me finding the time to write it all down. Not enough hours in a week.

1 Like
#24

I have two benefits to go JS-less way:

  1. When I use a new tool or technology I want to learn its ways rather than forcing paradigms I already know into it just to learn.
  2. I enjoy the challenge of writing things the TW-way, which reminds me of the old days of making games in the very limited Click Team software and having to overcome those limitations.

But when there’s no way there’s now way.

2 Likes
#25

For the last decade and maybe the next, I’ve been wanting to learn javascript, but I cannot stand it. It annoys the daylights out of me. Appreciate it, and appreciate the folk who create good stuff with it, but man is it ever not for me.

TiddlyWiki works the way I think, so it is a never ending joy for me as I’m always finding “how would I do this/that in TiddlyWiki” moments waiting for me around every corner to grab me by the jugular. Of course, do this/that within the boundaries of the DNA (which includes single-file, single-user, wiki, componentization bar-setter.)

#26

@Maurycy in the spirit of progress and communication please consider the following;

  • First, we all share a passion for a very specific area of interest, and thus must be friends and colleagues :nerd_face: .
  • It is fine for us to maintain different views or positions to each other, but I am trying to make clear I don’t think we need new JS to achieve what you want.
  • If a JS “fix” to a problem is created, one that is “not a JS problem”, it may offer some functionality, but it will only add complexity and mislead people to think is is necessary.
  • As I have stated elsewhere, I took a deliberate decision to remain a TiddlyWIki superuser rather than a core or JavaScript developer, and only stray into JS when there is a demonstrable gap. I ofent find its easy for people to revert to JS when they dont know how to do it in TiddlyWiki
  • In reality we are discussing a fairly complex set of technical issues and it is fine to disagree, I naturally prefer to discuss and dispute the claims of facts using an egoless approach, which we have so far, I think.

And as I argued strongly this above I believe this assertion is untrue.

“The key is the title”, and it is easy to ensure referential integrity especially when you implement the interaction for your subject area solutions. In the general the relink and the addition of other fieldnames is mostly enough.

To give you an example, see my solution here which allows you to add custom actions to any existing button https://all-button-actions.tiddlyhost.com/

  • Thus you can intercept most if not all “risks” to referential integrity.
  • Why do you have a technical term “JS” in the middle of a “requirement”?
  • I am sorry you feel that way, It is not intended, but please take home the following points to understand why I am resisting what you are saying;
    • I argue no JS is necessary, but even if it is, we have no evidence for this yet.
    • To move forward we need to discuss the details of ensuring referential integrity, not only in general.
    • Your argument is too broad, similar to a value judgement, we need to look at the individual issues and discuss them.
  • There are ways to protect yourself against this, including using shadow tiddlers and forcing the order of plugin application.
  • But then there is an issue here about where you draw the line, at what point do you prohibit change?, this is too hard for me to address in a dot point.
  • Difference and debate is critical to the evolution of ideas. Although it may feel uncomfortable it will contribute to shared understanding and progress.
  • I agree, but TiddlyWiki already has data integrity in many ways already, it is only in a subset of cases where we need to build additional features.
  • I understand where @Charlie_Veniot is coming from here, band for me as I have argued before don’t import another javascript solution to to solve a problem that does not exist. “A man with a hammer thinks everything is a nail” has never being truer when it comes to javascript solutions to tiddlywiki issues.
  • As deeply invested in the TiddlyWiki platform as I am, I am concerned this tendency over time is adding complexity by using “string and sticky tape” solutions to things that are either;
    • Not a problem after all
    • Need a minor change to the core to strengthen native tiddlywiki.
  • Please demonstrate this in detail and lets see if this claim is sustainable. Please try and keep it bite size.

Yours respectfully, seriously and your “tiddlywiki kin”

#27

Sorry, I won’t be able to reply to the entirety of your post.

I’ve said it multiple times but perhaps it got lost in the scope of a bigger messag.

Demonstration

I want to accomplish the following:

  • Deleting a tiddler with <$action-deletetiddler/> also deletes a tiddler linked to it.
  • Renaming a tiddler with tm-rename-tiddler also renames certain tiddlers linking to it via an arbitrary field.

My assertion is: neither of those can be accomplished without using JS (or a plugin which itself uses JS). The reason is TW has no wikitext mechanism to respond to hooks.

1 Like
#28

“Pseudo-code:”

define deleteThisTid($tid$)
<list thisTid filter="$tid$ sub-tasks">
<deleteThisTid sub_task>
</list>
action-delete $tid$
end


<button actions="""<deleteThisTid currentTiddler>""">
Delete this task and related tasks
</button>

Something like that.

#29

So you want to protect a tiddlywiki from a developer writing code without maintaining referential integrity?

  • Most users do not revert to code when using a solution you built, you can ensure that all uses of the delete action in the user interface handles this. See my all button actions solution.
  • But to do exactly as you ask see below;

For the hook you are looking for tiddlywiki may already have the tools for you to trap even new code being introduced; Have a look at;

To achieve this, use either of these widgets and wrap the code within which it will catch calls to a given message. Thus you may wrap the whole story, and or the page template.

  • A more targeted approach may be to use the cascade mechanism to wrap only tiddlers with a particular condition eg; has a field object-type[dbrecord]with a message capture. Whole of tiddler will catch the buttons, on the tiddler.
  • I think the <$action-deletetiddler/> will be generating the WidgetMessage: tm-delete-tiddler message.
#30

“Pseudo-code:”

define renameThisTid(tid newName)
<list thisTid filter="Get tiddlers that have $tid$ in a particular field">
set the field to the $newName$
</list>
rename $tid$ with $newName$
if that didn't work for whatever reason, then
<list thisTid filter="Get tiddlers that have $newName$ in a particular field">
set the field to $tid$
</list>
end


button actions="""<renameThis <<currentTiddler>>> NewTitle"""
Rename this task and related tasks
/button
#31

Install the relink plugin, which arguably could be in the core, and add the “arbitrary field” in which you want “titles” updated whether it can contain a single title or a list of titles.

#32

Relink was already ruled out. (Avoid dependencies.)

1 Like
#33

I am not 100% sure how viable it would be to replicate what my JS is doing with MessageCatcherWidget – my JS uses th-saving-tiddler hook (not a message). It should be possible but…

It won’t work in the context I mentioned earlier - I am writing a plugin. While I can technically shadow a core tiddler to use this widget it has this one big problem: only one plugin can do it at a time. And that assumes the TW user didn’t shadow that same core tiddler themselves.

So while MessageCatcherWidget is a great widget I didn’t know about before it still isn’t as versatile as required to use it in a plugin to improve data integrity. Unless, of course, there is a way to stack those across multiple plugins that can’t be accidentally shadowed by the TW user themself.

I am painfully aware of what XY Problem is and this is not the case. I know covering these cases might never pay off but I am still going to do so, be it with JS or not.

#34

I didn’t understand all the intricacies of this thread but if the quoted bit here is what you’re after then, yes, you can target specific tid titles with CSS to hide stuff in only those.

2 Likes
#35

As you have correctly surmised there are currently no wikitext affordances for using hooks. The message catcher widget intercepts widget messages, which are distinct from hooks.

Third party plugin dependencies are indeed a pain point, especially in the absence of a cross-library dependency resolution mechanism during plugin installation.

#36

You’re right, I even remember reading a thread a few days/weeks about just that :man_facepalming:.

#37

I was actually developing a plugin that would work a bit like global keyboard shortcuts at some point in the past but responding to hooks, but lost interest.

1 Like
#38

The solution I have been using privately is a very simple plugin that executes tagged tiddlers with a given tag for each hook, setting the appropriate variables. This works for most though not all use cases, such as those where you need to access properties of JavaScript objects. However, with the introduction of JSON operators in the core, this can now be further improved.

At some point we will want to introduce wikitext affordances for hooks into the core but this likely needs to happen hand in hand with a refactoring of the navigation mechanism to which much of the handling of hooks is currently tied.

Edit: here is an extremely early and limited version of executing actions from tagged tiddlers in response to a hook, that I baked into a plugin.

#39

Please do tell me if I may have something here,

I think this assumes you are using a plugin to introduce Javascript and you want to do the catching within that plugins javascript. A plugin can just include standard tiddlers that introduces the message catcher to the wiki as a whole.

That is you are right “It won’t work in the context” you are using but, “will in the context I am suggesting”.

  • As this indicates that same ultimate solution can be achieved with widgets.

My serious concern is if javascript hooks are developed to solve problems that we should solve in the core wiki text / widgets we force future solutions to use hooks. This locks out non-javascript solutions.

Ideally we first handle it in Wikitext and Widgets and then also introduce it for the more sophisticated JavaScript plugins. The two can and should co-exist but obvious, fundamental and required functionality, such as ensuring referential integrity, belongs in the core and accessible via widgets and messages.

#40

I have no idea what you are referring to. @Maurycy has expressed needs that cannot be satisfied with widgets. If you feel otherwise please provide a concrete example of how it would be accomplished.

I suggest reading my later replies more carefully, which focuses on the introduction of wikitext affordances in response to what are currently hooks only usable from JavaScript. These hooks already exist in the core and have for quite some time.

Adding core wikitext affordances for hooks isn’t a new topic and you have been involved in discussions around it as well. I would think that you would welcome this, as it extends the possibilities of what can be accomplished with wikitext.