Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#13 2024-04-06 02:30:34

Pat64
Plugin Author
From: France
Registered: 2005-12-12
Posts: 1,599
GitHub Twitter

Re: Variable tweaks

etc wrote #337029:

This does not help me much, but please try the latest commit, just in case.

Hooray.
Much better Mister etc.
All works perfectly now!

But now only this structure returns a result (where import do nothing):

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

Last edited by Pat64 (2024-04-06 04:23:26)


Patrick.

Github | CodePen | Codier | Simplr theme | Wait Me: a maintenance theme | [\a mi.ni.ma]: a “Low Tech” simple Blog theme.

Offline

#14 2024-04-06 08:55:53

etc
Developer
Registered: 2010-11-11
Posts: 5,057
Website GitHub

Re: Variable tweaks

phiw13 wrote #337030:

Perhaps related: I had the following at the start of shortcode form that is inserted inside the body (<txp:body />) of an article:

<txp:evaluate query='starts-with( "<txp:page_url/>", "/rss")' escape='trim,textile'>...

Up till now this worked fine (did not cause any error), but now I get the following error message when viewing an article containing that shortcode:

Tag error: <txp:page_url/> -> Textpattern Warning: page_url/ tag does not exist...

Looking closely, there is a missing space between _url and /. Once added the error goes away.

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.

Offline

#15 2024-04-06 09:26:24

etc
Developer
Registered: 2010-11-11
Posts: 5,057
Website GitHub

Re: Variable tweaks

Pat64 wrote #337032:

Hooray.
Much better Mister etc.
All works perfectly now!

Nice to hear it, thanks! But I’m still curious to know what happened.

But now only this structure returns a result (where import do nothing):

<txp:date format="%m" escape="integer" variable="month" />...

That’s because import has become alias, sorry. But all this part is still experimental, so don’t rely on it too much.

Offline

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

Pat64
Plugin Author
From: France
Registered: 2005-12-12
Posts: 1,599
GitHub Twitter

Re: Variable tweaks

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>

Patrick.

Github | CodePen | Codier | Simplr theme | Wait Me: a maintenance theme | [\a mi.ni.ma]: a “Low Tech” simple Blog theme.

Offline

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

etc
Developer
Registered: 2010-11-11
Posts: 5,057
Website GitHub

Re: Variable tweaks

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.

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,273
Website GitHub

Re: Variable tweaks

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?


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

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

etc
Developer
Registered: 2010-11-11
Posts: 5,057
Website GitHub

Re: Variable tweaks

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.

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,273
Website GitHub

Re: Variable tweaks

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.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

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

etc
Developer
Registered: 2010-11-11
Posts: 5,057
Website GitHub

Re: Variable tweaks

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.

Offline

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

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,599
Website

Re: Variable tweaks

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.

TXP Builders – finely-crafted code, design and txp

Offline

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

etc
Developer
Registered: 2010-11-11
Posts: 5,057
Website GitHub

Re: Variable tweaks

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.

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,273
Website GitHub

Re: Variable tweaks

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 :)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

Board footer

Powered by FluxBB