chaining jobs

[Jean-Pierre Rivière]

In my project I need to first create a new project with an identifier (an input data) then to offer a complete input of the project to the user.

I have crafted this macro invoked when the identifier is ready to be used.

\define insertProject(proto)

<$set name=project select=0 filter="[all[current]getindex[project]]">

  <$action-setfield $tiddler=<<target>> $index=<<project>> $value=""/>

  <$set name=autoref select=0 filter="[<project>addsuffix[/project]]">

  <$action-setfield $tiddler=<<target>> $index=<<autoref>> $value=<<project>>/>

  <$macrocall $name=editProject proto="$proto$" target=<<target>> id=<<project>>/>

</$set>

\end

this does indeed create an index within the data tiddler with the desired value. Then it prepares the data for the further input. So far so good. But the second input does nothing. With additional logging, it is shown that in fact this last part is called first! (this is the call to editProject).

I wonder wether that is but an illustration that in TW the order of the treatments cannot be guaranteed?

Anyway. can I achieve my goal? And how?

In the meantime, I'll just setup a message to do the edit by hand.

Could we dream of callbacks for action, that would be called after the action is done?

something like <$macrocall $name=insertProject $chaining=editProject/>

surely it would use variable instead of parameters as a way not to have too cumbersome a syntax in the macrocall. And it may very well not be on offer for a direct call like <<insertProject>>.

Regards.

-- 

Jean-Pierre

[PMario]

Hi,

I didn't test anything and also didn't read the code. .... BUT 1  end </$set> is missing.

-m

[Jean-Pierre Rivière]

True but it's not that.

I acn this of a kludge though. Since editProject is called but too uoon (immediatly), I could instead called a new macro callEditProjectASAP which would basically see if the new item is there until it is, with a sleep inbeween. and then call editProject. Not so simple IRL surely, for sleeping is not so simple in JS, needs a bit of things to do but tgen the problem is...

how can I code a javascript macro in TW5? Is it possible?

even more murky: make it call js through a filter. just as a way to call js if nothing else.or as regular html launched js (<script>).

All this seems promising of js fiddling I'd better avoid. Although I'd really like to know how to code a js macro.

[Eric Shulman]

On Thursday, May 6, 2021 at 5:24:11 AM UTC-7 jn.pierr...@gmail.com wrote:

In my project I need to first create a new project with an identifier (an input data) then to offer a complete input of the project to the user.

I have crafted this macro invoked when the identifier is ready to be used.

Assuming that your macro is triggered by a button press, you can split the actions into two separate parts.  The first part is specified in the body of the $button widget, and the second part  is specified using the actions=... parameter of the $button widget.  When the button is pressed, the "body" actions are performed (and *completed*) first, followed by the "parameter" actions.   For example:

\define target()         TargetTiddler

\define button_actions() <$action-setfield $tiddler=<<target>> timestamp2=<<now "0hh0mm0ss0XXX">> />

<$button actions=<<button_actions>>> click me

   <$action-setfield $tiddler=<<target>> timestamp1=<<now "0hh0mm0ss0XXX">> />

</$button>

When the $button is clicked, the "timestamp1" field is written first and then the actions=... is triggered, writing the "timestamp2" field.

Also, as a side note, the $set widgets in your code could be written more simply using $vars and "transcluded filter" syntax, like this:

<$vars project={{##project}} autoref={{{ [{##project}addsuffix[/project]] }}}>

Hopefully, the above code examples should get you pointed in the right direction.

enjoy,

-e

[Jean-Pierre Rivière]

Thank You Eric, my job chaining is now working!

And I know what to do next (hum... first :-) as a payback for the community: propose a change in the official doc that tells this feature you wrote. Because this is not tge case currently. At one point, it evens states that "Embedding the actions within the triggering widget (an older technique that is now deprecated)".

Just to be really true about this order thing, is it really true that nothing more can be warranted for the order of execution : no third batch, no order within each batch.

especially:

<$button>

<<macro-for-action-01>>

<<macro-for-action-02>>

</$button>

one cannot say anything about the order of execution of the <$action-XXX> within macro-for-action-01 AND macro-for-action-02 **relatively to one lot relative to the other  BUT ALSO within each lot? Maybe that defiance can be restricted to some features only?

Surely I should avoid being too precise: these (precious) details have to be written by experts.