Action-createtiddler fail option

#1

In a code of mine, I check if a tiddler exist and then display either a “sse” or a “create and edit” button. The later first issue an action-createtiddler widget, specifying the $basetitle with $overwrite=yes.

But… if a nasty tet of event had the target tiddler happening to come into existance before my buttons are redrawn, this tiddler would be lost! What about $overwrite having a third option: “fail”. $overwrite=fail would not rewrite an exititng tiddler (as for “yes”) neither attempt to make a new title for it (as for “no”).

IMHO it would help making more robust software. without any extra hassle.

#2

I tend to have a list widget testing if the tiddler does not exist first, only then create new and do something else when it exists.

#3

How should that happen? If there is a “filter function” somewhere in your code, that checks for the existence of a tiddler, it will be refreshed, whenever that tiddler is created.

Since the TW UI state depends 100% on the tiddler store, your error case doesn’t happen.

Except there is a bug, which needs to be fixed in the core and not in the widget “fighting the symptoms” instead of fixing the problem.

#4

@TW_Tones What you say is a relieve. Would it always be the case in a real multi-user setup with concurrent access?

#5

Multiuser will add more complexity, but you can structure your code and buttons to determine the latest info before acting (actions) and commit changes. It is also possible to use different design strategies to avoid name conflicts.

#6

Just to confirm that action widgets are executed synchronously, so it is not possible for another entity to modify the tiddler store in between the actions of an action string.

#7

@jeremyruston OK, no need to worry about this.

could this scenario apply, however?

1: I click on “see before deleting button”. computed data there, fine.
2: someone change the data. in a way that a button on my newly opened tiddler should be disabled.
3. before the new tiddler is automatically redrawn, I click on the fatal button
4: the new tiddler is redrawn.

With a slow machine, it seems conceivable…

#8

Yes, absolutely. In that example there are actually two separate action executions at (1) and (3), and it is indeed possible for other threads to to have modified the store in the meantime. In such situations one needs a secondary check in the action strings at (3). It’s very similar to the way that client-server systems work: rejection of invalid input is typically handled by both the front end UI code and the back end database code.

#9

@jeremyruston Thank you for all these clarifications.