In a typical input screen, I do tghe validation in 3 steps:
clear all errors (from previous attempt)
compute all errors
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?
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.
@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:
delete all errors and create new ones
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!
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 ?
@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!
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>
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.
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
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.
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
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?
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.
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!
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.
