Idea for macrocall especially for javascript macros

Developers
1

I’ve had a similar challenge over the years, but just thought of a different idea/approach that seems to make a lot of sense to me.

Because a lot of what I do with project management involves dates, I have to rely a lot on javascript macros to do date math. There are many such javascript macros out there. I’ve taken add-time and date-diff from @inmysocks and modified for my needs for instance.

The issue is that (as far as I know) there’s no way to “use” the value returned by a <$macrocall> widget right now other than store it in a macro and use a <$wikify> to store it in a variable. Minimizing the use of <$wikify> is a common suggestion for performance reasons, I’m curious if extending the <$macrocall> widget to work like a <$list> or <$set>/<$vars> where the “content” can expose a variable to be used - either within filters or anything else is a good idea.

In case that was confusing, here’s an example of what I’m suggesting…

Today (pseudo-code):

\define new-date() <$macrocall $name="date-add" basedate={{!!date}} days={{!!days}}/>

<$wikify name="new-date-wikified" text=<<new-date>>>
<$list filter="[tag[Task]due<new-date-wikified>]">
</$list>
</$wikify>

Would become:

<$macrocall $name="date-add" basedate={{!!date}} days={{!!days}} variable="new-date">
<$list filter="[tag[Task]due<new-date>]">
</$list>
</$macrocall>

There are other things I’m considering for this specific use-case around dates. For instance I think a long time ago @saqimtiaz suggested making a filter operator out of these date macros which does make sense, and the ability in 5.2.0 to use parameters within macros in filters helps too, but independently the <$macrocall></$macrocall> thing seems useful too. Just curious in thoughts from the devs on the idea.

2

The problem is, that the macro-call widget is a general purpose widget, that can be used for every macro. Be it a js or a wikitext macro. …

Your proposal would make it to have side effects that exactly fit your usecase. … What if my usecase needs 2 variables and someone elses usecase works completely different. … I think you see the dilemma. …

The problem is, that you shouldn’t use javascript macros, because they are the wrong tool for the job you want to do.

If you would create an <$add-date widget, you would exactly get what you want in a way that aligns 100% with TW.

Your call would be:

<$add-date basedate={{!!date}} days={{!!days}} variable="new-date">
<$list filter="[tag[Task]due<new-date>]">
</$list>
</$add-date>

e-voila … Creating widgets that “only” create variables and have no visual component actually isn’t much harder, than creating js-macros.

Have a look at the <$vars widget

… The rest is boilerplate. … kind of :wink:

It would be nice to change VarsWidget to AddDateWidget … to avoid confusion. … But for testing the 3 points above should work already.

3

I agree with most of what @pmario has said, with the exception that I would implement it as an add-date[] filter operator instead. Not only will that be more versatile, but filter operators can be a lot easier to write than widgets.

4

Fair points @pmario and @saqimtiaz - I’ve not yet attempted it but will do so. I appreciate the extra detail on the “why” @pmario.

5

I’ve wondered if we can retroactively add a “type” suffix to the maths operators like add:date, subtract:date. It would match the compare operator.

3 Likes