Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
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
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
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
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
Re: Variable tweaks
Great, then we have to decide
- whether this
alias
(or whatever name) feature, currently supported only byquery
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
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
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
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
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
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, thealias
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
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
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