Detect save process complete before doing next action (and other tiddlywiki actions issues)

Developers
#1

Folks,

I am raising this here because it is developer’s who more likely to be able to understand and answer this question, I also expect it to be of less interest to the community in general. Perhaps the answer also needs a developer solution.

I have a set of actions where I wish to do the following;

  • Set some fields and tiddlers to some value
  • Save the Wiki (assume autosave is possible ie no need for default saver)
    • eg On GitHub, tw-receiver and Timimi
  • Set some cookies
  • Reload the wiki

Observations

  • During some tests, I found the reload occurring before the wiki was saved, thus loosing the changes to fields and tiddlers.

Design considerations

  • Although just testing with buttons I aim to move the set of actions into startup actions and I want them all to take place before the user gets access.

The Question(s)

  • Is there a way to, not proceed to the next action until a save tm-save-wiki action is reported completed?
    • If not could the tm-save-wiki action just not return control until it completes?
  • Perhaps an alternative to the ActionConfirmWidget but not necessarily interactive could be designed to proceed only after saving completes.
  • Could the reload action, if nothing else, test for and wait for save completion?
  • Failing any of the above would it be possible to trigger the save then have a timed wait before proceeding to the next action, not unlike ActionConfirmWidget but for a time only. Perhaps displaying a count down and message. “Please wait N seconds”.

Final note;
If a solution does not exist yet and one needs to be developed I can use the interactive ActionConfirmWidget in the mean time, however if a solution must be developed, could we try and make it generic in nature that it has a broader application?

For example improve the ActionConfirmWidget to accept one or more of the following;

  • The interactive confirmation (current)
  • Confirm when save completed
  • Confirm when N seconds has passed
#2

Event-driven programming, the kind in which you need a timer to trigger checking for a particular condition.

You’ll need something like the OokTech/TW5-TimerActions, dynamically creating a timer upon a certain event with a specified action (or set of actions) to perform upon each interval. In your case, check for the existence of some condition, and perform some action(s) when the condition exists.

(Upon existence of the condition, end the timer, and perform the actions.)

There may be “architectural” reasons, TiddlyWiki proper or plugin, why it can’t work (for example: can a timer’s actions stop the related timer?)

I’m thinking it would be an extremely fun exercise for somebody who has the time to spare.

1 Like
#3

Well, a potential kicker: how do you block the user from interacting with TiddlyWiki between the “start” of the process and the reload trigger?

If you are the only user, then you’ll know to be hands off.

One way to block any user from doing anything: a modal window with no close button and a clear message that says “do not touch, TiddlyWiki is in the process of reloading.”

Not sure whether or not that’s enough.

The entire process may be lightning fast, but let’s not underestimate the speed at which folk can perform some action that borks things.

1 Like
#4

Charlie,

Yes thanks for that, I have taken this into account. In the application I am working on some startup actions to check for some conditions and if true, make changes, save the wiki and reload. The user never gets to interact until the wiki reloads in a particular state. So in this case this is not an issue.

If I am forced to use a timer (to give the save time to complete), because the other possibilities are not available, I will consider “Run once after some interval” from OokTech/TW5-TimerActions or perhaps Eric has something in TimerTools

Your points however do go to the subject of;

if a solution must be developed, could we try and make it generic in nature that it has a broader application?

I understand the idea of using the modal to take over the UI, which is a useful method. However it is worth noting this may not be necessary if;

  • Actions bundled together under one trigger may run quickly. if they can run in parallel then they can step on each others toes. A way to force the serial execution of actions as a rule (if needed) would be another solution.
  • There may be an argument for actions that can be initiated in the background eg save wiki to return interactivity to the user so they continue. In which case there may be another trigger that initiates an action that depends on the prior action completing and we want this second actions to be able to check or wait for the condition to be true.
  • If we could time events we may be able to adjust a timer based on previous save times.

Just thought I would add here that perhaps we can use progress pie charts

#5

I would get into instant paralysis by analysis trying to figure out the interval for run once.

To avoid that, I’d be going with dynamic creation and start of the timer upon whatever event, with extremely short intervals to keep quickly checking for the “end-of-process” condition to then trigger the reload.

But I’ve got Windows API and OpenText Gupta Team Developer programming and related “Drop-kick me Jesus through the goal posts of life” moments in my head, so there may be some bias there that doesn’t apply or can’t be handled by TiddlyWiki, or the plugin, or both.

#6

Charlie,

I agree triggering a timer make sense in many cases, one area that was raised as an issue before was when it comes to saving. If its not automatic and fairly prompt, the big example being if the save needs to use the default save and the download/file save dialogue is used, then the time it takes will depend on the interactive user, they may start but then get a phone call or leave for the weekend. :unamused:

now I digress;

:thinking: It reminds me when working in a supermarket I learned,

It would be a ‘‘great job’’ if their were no customers,
but it would not be a job, if their were no customers.

and so we can say

Writing software would be great if there were no users…

In fact, that was the way it was when I started as professional programmer, I used to write batch programs, however users often found something to complain about in the output. Although I wrote advanced interactive programs with “advanced basic”, I soon migrated to the twilight of interactive mainframe programing, although that was hard, especially when I had to reverse engineer a online IBM Mainframe CICS application, I have some funny anecdotes from then.

What odd is how the same technologies return in different guises, Modern browser apps still basically work the same way as mainframe transaction environments, except tiddlywiki :clap:.