Later-actions for $button?

#1

In a typical input screen, I do tghe validation in 3 steps:

  1. clear all errors (from previous attempt)
  2. compute all errors
  3. if any error, just keep input else finish input, save data and close tiddlers.

step 3 needs step 2 which neeeds step 1. By need I mean that step 1 and step 2 do modify the tiddlers fields according to theirs computations.

Alas, we only have two steps with a button. This leads to more complex coding than strictly necessary and a bit obstrufucated. Time consuming both at writing, debugging and even reading.

Could the be a later-actions tag for $button that would be just like actions but called after actions has been fully done (fields and index committed to disk)? This would solve my problems. Am I alone in such a need?

#2

Have you considered using the ActionConfirmWidget within your set of actions?

You can have more than one button when going from A to B even if you make them look like the same button to the user.

Although not directly related to your case here I recently created this for developing batch actions buttons.

#3

If it’s not too much of a rewrite for you…

You could make sure all your buttons implement three stages:

  1. <<actions-stage-1>> then calls
  2. <<actions-stage-2>> then calls
  3. <<actions-stage-3>> (then calls… ?)

Of, if you prefer:

  1. <<actions-begin>> then calls
  2. <<actions-main>> then calls
  3. <<actions-end>>

Of course, if you’re expecting something a little more organic like…

<$button actions-begin=<<actions-1>> actions=<<actions-main>> actions-end=<<actions-3>> ... >

you’ll need to make your case on GitHub.

#4

You can handle all three stages in the actions attribute of the $button widget after setting tv-action-refresh-policy to yes. This forces all widgets to refresh themselves before execution, picking up any new values saved to tiddlers or variables in previous actions.

See https://tiddlywiki.com/#ActionWidget%20Execution%20Modes

#5

@TW_Tones What is the use of ActionConfirmWidget if there is no popup ? Is that the way to chain step the way I wished for in my request? (I have not tried so far).

As for this original pledge of mine, I have finally found out a nice way to do it in 2 steps:

  1. delete all errors and create new ones
  2. check for errors and act accordingly.

I was relieved to see that tge first step went OK. I must have fumbled somewhat while trying to get my code correct, as it seems so obvious, I wonder what mistakes I must have done!

I have to add that some inputs needed transaltion before checking, and how and when to do it was the details that lead to my wpongdoing. But now I made it simple and clean. I’m relieved! :slight_smile:

#6

If we try the example of the doc pointed by @saqimtiaz we can no more change the value of the text of ActionTestTiddler. Is that not because of the “always” policy being still active?

Would it not be better if we (could) code instead:

\define actions()

\define tv-action-refresh-policy() always

<$action-setfield $tiddler="ActionTestTiddler" $field="text" $value="FOO"/>
<$set name="newvalue" value={{{ [{ActionTestTiddler}lowercase[]] }}}>
<$action-setfield $tiddler="ActionTestTiddler" $field="text" $value=<<newvalue>>/>
</$set>
\end

Current value of ActionTestTiddler: {{ActionTestTiddler}}

<$button actions=<<actions>>>
Click me
</$button>

so that we are sure that the policy is only restricted to our function ?

#7

@CodaCoder I don’t really see what coding you have in mind. I don’t want such a specific coding if it’s not interesting for many people: it would just mean that there are better ways. See my question first as a question about the relevant status for my idea.

However, I have a relative idea in that I wish for a simple way for each macro that want it, to reject the call if pre-condition are not met and interrupt the interpretation flux if its post-condition are not met (but I would be satisfied if I only had the pre-conditions working). I have no idea how such a beast could take shape!

#8

I do not follow what problem you are describing. However, as the documentation explains, tv-action-refresh-policy is a variable. So the example you propose would be written as follows:


\define actions()
<$let tv-action-refresh-policy="always">
<$action-setfield $tiddler="ActionTestTiddler" $field="text" $value="FOO"/>
<$set name="newvalue" value={{{ [{ActionTestTiddler}lowercase[]] }}}>
<$action-setfield $tiddler="ActionTestTiddler" $field="text" $value=<<newvalue>>/>
</$set>
</$let>
\end

Current value of ActionTestTiddler: {{ActionTestTiddler}}

<$button actions=<<actions>>>
Click me
</$button>
#9

You should ignore my proposed solution – I was not aware of the tv-action-refresh-policy variable before I posted. Also, as I hinted, it would be a lot of work to rewrite to support it.

Note: I assume in @saqimtiaz’s original, he meant to assign “always”, not “yes” as I don’t see “yes” mentioned in the linked article. Unless, of course, there is a meaning for yes that remains undocumented…?

My new understanding is that Saq is proposing you don’t need your step 3, since tv-action-refresh-policy set to always would obviate the need.

#10

I thought that there may be cases where you could use the ActionConfirmWidget to help stage a process to the next step. The process may not need confirmation but it allows you to break one step in two, with a conditional “continuation”.

On your first post, I think it may be a little too general in some ways and I am not sure I understand;

You see one button is “one click” but within it you can have multiple steps

<$button>
<<step-1-actions>>
<<step-2-actions>>
<<step-3-actions>>
label
</$button>
  • Within the actions macros or in the button widget you can wrap the actions macros in conditions including but not limited to the modified variable for held keys like ctrl
  • ie one cation can be conditional on the result of a previous one.

But then buttons can also be in series with conditionals, so you could have say three buttons but only one of the three shows at a time, click action and display to the next button. If you gave them all the same name the user would be none the wiser than thinking it was the same button each time, however to motivate action the button is more likely to prompt clicking, through its button name.

  • I have often had a replacement button appear only after the first has done its job successfully.

In your three step example “if any error” could display (again) the “compute all errors” button, but if no errors just close the tiddler.

Personally I find building multi-step processes first manually, where the user/designer/I have to interact every step first, is a good way to build and test my code, but as I become more aware of the detail in the steps I see ways to “collapse a number of steps into a smaller number of steps”, sometimes even eliminating any interaction altogether.

#11

Perhaps @jypre can confirm, but when he said…

I thought he was talking about these “steps”…

\define step1() <$action-log $$message=step1 />
\define step2() <$action-log $$message=step2 />

<$button actions=<<step2>>>Click me
<<step1>>
</$button>
#12

I thought he may be as well, but within moth of these you can include multiple “steps”, including;

  • conditional steps
  • modifier steps
  • Action confirm

Then you can also place buttons in series etc… all creating more “steps”.

#13

Sorry for being so late to reply. By step, I meant a succession of operations that can go forwards without having to consider the results. A new step arrive when you have to check the results so far to decide what to do.

As I said, for my initial problem, I found a way to operate in two seps, as @CodaCoder exposed.

That’s why I don’t think the tv-action-refresh-policy is any help for me. Besides, I cannot see any results if I click the button of the demo in the doc of this feature.

I wonder if action-confirm would allow the introduction of another step? say thact step1 is in fact

\define step1()
<<step1-1>>
<$action-confirm prompt=no><<step1-2>></$action-confirm>>
\end

Would I really have two steps within step1 (with step defined as I previously wrote)?

Would the code below allow for three steps?

\define step1()
<<step1-1>>
<$action-confirm prompt=no>
  <<step1-2>>
  <$action-confirm prompt=no>
    <<step1-3>>
  </$action-confirm>
</$action-confirm>>
\end
#14

I’m lost, unless you’re trying to create a wizard (doesn’t sound like it, though).

#15

Like,

me too,

However I am not sure what you think is missing;

  • condition means wrapping content, buttons or actions inside a list or reveal widget.
  • If a refresh is needed you can set tv-action-refresh-policy to yes

Here are three steps one after the other, without condition.

<<step1-1>>
<<step1-2>>
<<step1-3>>

You can have a macro

  • That contains more than one button, however each can display based on a condition,
    • such that two buttons may only look like one by never displaying at the same time
    • A subsequent button may only appear once the result of a previous button is available.
  • Any button can have actions within it or via actions=<<macroname>>
    or actions={{tiddlername}}
  • Any set of actions can contain a exactly that a set of actions
  • Any action or set of actions can be wrapped in a list or reveal
    • Such as to use the [<modifier>match[ctrl]]
    • Or to only execute the actions according to conditions (possibly set by a previous button or action).
  • If an action confirm is used
    • and you confirm it will execute all the actions within it, if not it will not execute all the actions within it and move onto the next step if any.
    • If action-confirm is used without content it merely delays progress until either response is given.
  • If there are things that change in one action that a condition test, or the second step needs to make use of, and is not yet available you use tv-action-refresh-policy to yesto cause a refresh of each widget just before it is used eg updates the parameters to the widget.

Perhaps you can provide exact rather than a hypothetical question?

#16

:boom:

     

#17

In your original post it sounds like you want to be able to execute further actions that can correctly pick up any alterations made to tiddlers by prior actions. The tv-action-refresh-policy variable was introduced precisely for this need. If that is not sufficient for your use case, please share a minimal sample of code that illustrates the problem.

#18

Many many thanks @TW_Tones for all this clever tips!

I think I found all my answers there.

Now, to be a little more clear, I have to say that I mainly spoke of conditions where most of the times I was thinking about availability of transformed data for further transformations. This is where tv-action-refresh-policy can help if need be (Many thaks also to @saqimtiaz for this one!). As for the times whre a choice has to be made, the tricks using <$reveal>and actions={{tiddler}} could be very handy sometimes.

Meanwhile, I also found out that some little tweaks in the way to operate could give the same results in the same numbers of step (2 steps at most) but that this is not necessaril easy to figure it out and that experience is the key resource here!

1 Like
#19

@jypre I am glad we can help, Whilst on this subject concider having a look at this How to have your code and action it too - batch operations on multiple tiddlers, refactoring your wiki

It it I discovered you can mix wikitext and actions in your code, if you let it render visibly you can see all the intermediate results and whatever you choose to display.

If you then wrap the same code in a trigger such as the button that now refers to that same code as actions, the actions will be “executed” and the other wikitext effectively ignored. This allows you to see the logic and outcomes before you action them using the very same code, so no need to separate the two, and possibly introduce errors or typos.

If you want to do some complex logic behind your actions or buttons this may be the best way to build and test you code.

Over the years I have learned building your code with visible progress, in a step by step way is very helpful, it helps address some of the fragility still in tiddlywiki code that can make debugging difficult, especially inside otherwise invisible conditional action widgets. It also helps “learning opportunities for reusable patterns”,and elegant modular solutions.