Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Textpattern evaluation (dis)abilities
It’s pity to introduce a new tag that is just “opposite” of an existing one, but I have to admit that
<txp:show ifdata>...<txp:else />...</txp:show>looks more natural than its hide equivalent. But then <txp:show>...</txp:show> (without attributes) sounds strange.
Offline
#38 2016-11-06 20:44:58
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: Textpattern evaluation (dis)abilities
One of the beauties of Textpattern is code readability and whilst I can see a functional connection with txp:hide, I’d prefer something more self-explanatory such as <txp:show ifdata> or even <txp:if_data>.
Offline
Re: Textpattern evaluation (dis)abilities
etc wrote #302706:
[…] But then
<txp:show>...</txp:show>(without attributes) sounds strange.
Yes if we would introduce a new tag I would think about something clother to adi_if_content. <txp:if_content> or <txp:if_data> would follow the usual Txp conditionning way.
Last edited by NicolasGraph (2016-11-06 21:27:54)
Offline
#40 2016-11-06 21:00:42
- jpdupont
- Member
- Registered: 2004-10-01
- Posts: 752
Re: Textpattern evaluation (dis)abilities
gomedia,
etc : +1. <txp:show /> seems more natural, logic.
Offline
Re: Textpattern evaluation (dis)abilities
gomedia wrote #302709:
One of the beauties of Textpattern is code readability
I guess that I agree with Adi. What about:
<txp:hide unless="tag1,tag2">
<h1>Here's an article list</h1>
<txp:article />
<txp:else />
<!-- Nothing -->
</txp:hide>Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Textpattern evaluation (dis)abilities
colak wrote #302721:
I guess that I agree with Adi. What about:
<txp:hide unless="tag1,tag2">...
I like the unless attribute but wouldn’t it start to be confusing when <txp:else /> is needed (hide unless, else…). Too much “alternative” things for my brain. ;/
Last edited by NicolasGraph (2016-11-07 09:15:03)
Offline
Re: Textpattern evaluation (dis)abilities
I guess the big question here is whether we should upgrade the txp:hide tag that much.
For now it is mostly used
- for not executing txp or other code we might not want to delete just yet
- Insert comments which we might not want them to be visible in the source of the front end.
I understand Oleg’s logic to reduce the tags but to achieve that, we may need to invent another one. A swiss army knife of tags which could be readily used in all contexts, as well as it being easily readable to non programmers.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Textpattern evaluation (dis)abilities
NicolasGraph wrote #302728:
Too much “alternative” things for my brain. ;/
colak wrote #302738:
I guess the big question here is whether we should upgrade the
txp:hidetag that much.
Yep, it looks to much for <txp:hide />. I guess, we still can give it process attribute (to say process but hide) and, maybe, enhance it in some other way? But unless we drop the else part (or drop the idea completely), a new name seems to be the only readable solution.
Offline
Re: Textpattern evaluation (dis)abilities
Which makes me wonder if <txp:evaluate /> could fit?
<txp:evaluate query="2*2=4" />
<txp:evaluate test="article">
<txp:newer /><txp:older />
<txp:article />
<txp:else />
Nothing new
</txp:evaluate>At least, it would give this threads title some sense :-)
Offline
Re: Textpattern evaluation (dis)abilities
etc wrote #302740:
Which makes me wonder if
<txp:evaluate />could fit?
Yes, it’s way better than the hide-plus-else combo. And gives extra abilities to evaluate arbitrary stuff, so I’m for it.
Adding process or some other attribute enhancements to <txp:hide> is fine, too. I think the problem in the current implementation is that it shouldn’t support <txp:else /> or people are going to get mighty confused. Remove ‘else’ support and the problem goes away.
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
Offline
Re: Textpattern evaluation (dis)abilities
etc wrote #302742:
Fine, we are two! If it gets some kind of consensus, I can do it quickly.
Make that 3. I kinda like the simple idea (hide if a condition is not met), like the prev/next nav example you gave upthread. The process idea, maybe I get it as well. But adding the <txp:else /> in the mix becomes very strange and confusing.
As for the <txp:evaluate />, hmm, maybe? How is actually different from playing around with <txp:variable />? Readability?
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline