Variable tweaks

Pat64 · 2024-04-07 03:08:07

Thank you lot!

That’s so clean, efficient and extremely useful:

<txp:date format="%m" escape="integer" variable="month" />
<txp:evaluate query="$month >= 4 and $month <= 8" alias="month">
The living is easy!
</txp:evaluate>

etc · 2024-04-07 08:39:07

Great, then we have to decide

whether this alias (or whatever name) feature, currently supported only by query attribute of <txp:evaluate /> tag, is useful
- in some other tags
- in all tags (via a global attribute)
is $varname syntax clear enough, or it should be replaced by more common {varname} or ?varname or other pattern
should substitutions happen automatically (can be expensive) or we need to trigger them somehow.

Bloke · 2024-04-07 09:53:55

I can envisage application in other tags. Conditionals, mainly. But as many tags take a default or else case anyway (e.g. <txp:article_custom>) if it’s not too expensive to implement alias globally then that doesn’t limit people’s creativity. Not sure.

I’m fine with $varname but I’m a coder. So in the interests of making it more universally applicable – and also perhaps easier to include symbols like hyphen or dot that would make coding more difficult behind the scenes if we only prefixed names – maybe {varname} is more robust and clearer? At the expense of an extra character.

I would also only substitute on demand, for performance. Presumably, the trigger would be presence of alias?

etc · 2024-04-07 10:25:11

Bloke wrote #337037:

if it’s not too expensive to implement alias globally then that doesn’t limit people’s creativity. Not sure.

Me neither. It’s not too expensive, but if there is only few use cases, the value/cost ratio would be weak. Besides that, to implement it we’d have to decide whether substitutions happen before or after the attributes are parsed.

maybe {varname} is more robust and clearer?

It certainly is, save if varname contains curvy braces, but this is an edge case.

I would also only substitute on demand, for performance. Presumably, the trigger would be presence of alias?

I agree, automatic substitutions are expensive and hazardous. Now, how the trigger should work depends on whether alias is global or not. If it is, we should also indicate the attributes where the substitutions must take place, to avoid useless processing.

It looks like we’d better keep it local atm. But please feel free to suggest other use cases, anyone.

Bloke · 2024-04-07 10:40:23

etc wrote #337038:

if there is only few use cases, the value/cost ratio would be weak.

True. Especially since most attributes match to a single value, there isn’t much scope for more nuanced logic in other tags or attributes.

The only time it would be of importance to other tags, therefore, is to save repeating yourself if you wanted to use the same expression in a few tags. We can already do that of course by setting a <txp:variable> but it still needs to be put in, and care needs to be taken over quoting/apostrophes.

Using alias cuts down complexity (visual clutter), potential parsing time (attributes-in-attributes) and maintenance (change once, use many). All noble goals that add power and flexibility.

we’d have to decide whether substitutions happen before or after the attributes are parsed.

Hmm yeah. My gut says before so all info is available to them when the expression is evaluated. But there could be edge cases. Maybe default could be before, but some sort of syntax like we do with other tags [1] to defer processing could be implemented? Not sure.

how the trigger should work depends on whether alias is global or not. If it is, we should also indicate the attributes where the substitutions must take place, to avoid useless processing.

Agreed. I’m fine with keeping it local. There probably aren’t enough use cases across all tags to warrant a global attribute. More work though, to consider which tags it should be supported in.

etc · 2024-04-07 11:01:44

Bloke wrote #337039:

My gut says before so all info is available to them when the expression is evaluated.

That can only be done globally in our current workflow, since when the tags are called, their attributes are already parsed. Could be risky to change it at this point.

I’m fine with keeping it local. There probably aren’t enough use cases across all tags to warrant a global attribute. More work though, to consider which tags it should be supported in.

Me too, and we could easily turn it global in txp5 if necessary. For the record, I came with it when considering if_date companion tag to <txp:date />. The conclusion was that <txp:evaluate /> would do it as well (and even better), but the construction lacks readability. Have not found other realistic examples atm.

jakob · 2024-04-07 14:29:39

Late to the discussion here, but I love this idea. I use variables liberally and the tag constructions get unwieldy. My favourites of all the above is much like what’s been discussed:

{placeholder} type notation.
triggered by presence of alias (or similar) attribute. Presumably, the alias attribute could take several comma-separated variable names?
while I haven’t got an example to hand, I could imagine this simplifying readability in other tags too.

etc · 2024-04-07 14:40:17

Since we are implementing it only in <txp:evaluate /> atm, I’m inclined to keep $varname notations, which are XPath variables. If one day we decide to develop extra DOM functionality, injecting txp variables into DOM would be seamless this way. This implies though that concerned variable names must be alphanumeric.

And yes, alias can take multiple values.

Bloke · 2024-04-07 16:27:10

etc wrote #337042:

If one day we decide to develop extra DOM functionality, injecting txp variables into DOM would be seamless this way.

Ooh, a nice win. Oki doke.

This implies though that concerned variable names must be alphanumeric.

We’ll cope, I’m sure :)

phiw13 · 2024-04-08 01:31:53

etc wrote #337033:

This is because the valid symbols set is largely extended in dev (e.g. <txp:©1€ /> is a valid tag name). But / should definitely not be part of it, fixed.

Now all works fine, both with and without a space() before the closing / in the txp:tag. TY.

phiw13 · 2024-04-08 01:53:20

etc wrote #337042:

This implies though that concerned variable names must be alphanumeric.

Interesting (I am a bad person):

<txp:date format="%m" escape="integer" variable="a月b" />
<txp:evaluate query="a月b >= 4 and $a月b <= 8" alias="a月b">
Some lovely weather wraps around a month of heavy rains
</txp:evaluate>

Works just fine, but name the variable as variable="月" (omitting the ASCII characters) fails with Warning: DOMXPath::evaluate(): Undefined variable Issue detected while parsing form p_test.

Bloke · 2024-04-08 05:43:47

This might be PHP. Its definition of a variable is one that begins with an ASCII alpha character. You can’t even have a variable called “1var” in PHP. It’s illegal, afaik.

phiw13 · 2024-04-08 06:09:30

Bloke wrote #337046:

This might be PHP. Its definition of a variable is one that begins with an ASCII alpha character. You can’t even have a variable called “1var” in PHP. It’s illegal, afaik.

Correct about starting with a digit, that fails. But I wish it was that simple :-(
variable="£" is all peachy, but € or ¥ ? Don’t go there…, even variable="a€b" throws errors:

Warning: DOMXPath::evaluate(): Invalid expression Issue detected

That inconsistency annoys me, as it makes it more difficult to define what characters you can use.

Rule of thumb: a-zA-Z0-9 (that includes the hyphen (hypen-minus, U+002D). The underscore might pay as well!

Last edited by phiw13 (2024-04-08 06:10:26)

etc · 2024-04-08 07:08:41

Well, must (in ‘be alphanumeric’) actually means should. The true name restrictions are

not contain , (comma) or | (pipe)
end with a-zA-Z0-9_ (to match \b regex pattern)

The reason is the regex patterns used in replacements. Blindly replacing $doll with its value in 20 $dollars $doll would be hazardous, and I don’t feel like writing a full-power XPath syntax parser. But if you say it’s ok (for blind replacing), it’s easily doable.

I vaguely hope to ultimately transform these $varname into true XPath variables and leave the hand to DOM parser, but it means $varname must be valid XPath-wise. So we’d better cope with it from the start.

phiw13 · 2024-04-08 08:11:06

etc wrote #337048:

Well, must (in ‘be alphanumeric’) actually means should. The true name restrictions are

not contain , (comma) or | (pipe)

end with a-zA-Z0-9_ (to match \b regex pattern)

Is it? I see many failures (post above, variable="a€b"), but also, starting with a digit seem so work (sometimes?).

The reason is the regex patterns used in replacements. Blindly replacing $doll with its value in 20 $dollars $doll would be hazardous, and I don’t feel like writing a full-power XPath syntax parser. But if you say it’s ok (for blind replacing), it’s easily doable.

It is not for me to decide what is OK or not, and you certainly have a better view of what is possible, what the limits are and what you think you’ll be doing with all this in the future.

I vaguely hope to ultimately transform these $varname into true XPath variables and leave the hand to DOM parser, but it means $varname must be valid XPath-wise. So we’d better cope with it from the start.

So from the start a good definition or description of allowed characters

Textpattern CMS support forum

#16 2024-04-07 03:08:07

Re: Variable tweaks

#17 2024-04-07 08:39:07

Re: Variable tweaks

#18 2024-04-07 09:53:55

Re: Variable tweaks

#19 2024-04-07 10:25:11

Re: Variable tweaks

Bloke wrote #337037:

#20 2024-04-07 10:40:23

Re: Variable tweaks

etc wrote #337038:

#21 2024-04-07 11:01:44

Re: Variable tweaks

Bloke wrote #337039:

#22 2024-04-07 14:29:39

Re: Variable tweaks

#23 2024-04-07 14:40:17

Re: Variable tweaks

#24 2024-04-07 16:27:10

Re: Variable tweaks

etc wrote #337042:

#25 2024-04-08 01:31:53

Re: Variable tweaks

etc wrote #337033:

#26 2024-04-08 01:53:20

Re: Variable tweaks

etc wrote #337042:

#27 2024-04-08 05:43:47

Re: Variable tweaks

#28 2024-04-08 06:09:30

Re: Variable tweaks

Bloke wrote #337046:

#29 2024-04-08 07:08:41

Re: Variable tweaks

#30 2024-04-08 08:11:06

Re: Variable tweaks

etc wrote #337048:

Board footer