Templating changes in 2021.10.0

Configuration
21

Yep. It will just be a PITA to change every single template to add that :wink:
It could just have been the “error” return value by default.

Forcing to code a nonsensical default value is … nonsensical :slight_smile:

1 Like
22

Funny thought: shouldn’t there be a default default value?

“Ensure you supply a default value because there’s none by default.” :slightly_smiling_face:

23

We’ll see how many need to be updated. I’m going to update tonight. TBH I doubt it will change much other than a bunch of warnings in the logs. IMO, warnings don’t bother me. I just ignore them unless they are bad.

24

Well… :wink:

I can already picture the forum filled with “My template stopped working” :smiley:

1 Like
25

yah but that means it will return ‘’, i.e. unavailable.

26

Not sure. That sounds more like “exception” → “error” to me …
It depends whether they’ll check if there is a default, or just fail if the rendering fails, which is very fine by me

27

Effectively, they’re removing the existing fixed default (which can be as lame as just reporting the original value, but it’s still something) and now allowing the user to supply their own default … except they must supply it because there’s no longer a default default. :thinking:

Yes, come December, there may be a lot of ‘busy work’ for everyone who hasn’t yet supplied default values.

28

they no longer regex templates, so I would assume it’s the latter. The only issue would be if they destroy the listener when this occurs.

1 Like
29

That one is very, very lame, imho, as you cannot test it…

30

Well you can, just check the output against the input. That’s what I always do in python

31

Indeed… Won’t work with timestamp_local(default=now()) == now(), though, so that one is not an option.
Probably, timestamp_local(default=0) == 0 will be the easiest.

32

Can you explain why the first test, using now(), not work but the second one will? Is it because there might be a few microseconds of difference between the two instances of now()?

33

Yes. now() will be evaluated at the time of invocation, then a second time at the time of comparison.
That’s theoretical, though. It might work, but isn’t safe anyway.

34

It would work if you set a variable as now

35

Ofc, but that starts to be a whole lot of coding and resources for a bloody useless default :smiley:

36

A post was split to a new topic: Template errors (no default)

37

I’m trying to figure out what problem they are trying to solve with forcing users to add defaults to all the filters all of a sudden?

Templates have worked fine forever (of course there may be some edge cases - there is for everything) so why make everyone go thru the trouble now to add this to every filter template?

What’s the purpose?

1 Like
38

You should watch the release party sometime. You’ll get a firsthand peak into the reasoning being things, including this.

39

FWIW, I just helped someone who didn’t understand why they are now getting a warning for this:

'00:00' | timestamp_custom('%H:%S', False)

We both know that’s invalid. In previous versions, the function wasn’t getting what it needed so it quietly did nothing and passed along the string. Now it warns the user that this isn’t valid (it needs a timestamp, not a string) and, unless a default value is supplied, the December release will flag this as an error.

Unfortunately, the user didn’t understand the warning message and was confused by its presence because the template “worked before”. In this case, “worked” was by pure chance because the input was already in the desired output format (the timestamp_custom function isn’t even needed here)

40

That’s good, no question about it. But what will happen now is that users will just blindly paste some snippet with a default and forget about it.
The warning is gone, but the issue is still there, which basically solves nothing.

Also, the (currently) warning is pushed at each scan_interval.
That’s a pretty good incentive to fix those asap :slight_smile: