Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: <txp:if_yield>
Gocom wrote:
<[txp|namespace]:anytag txp:encode="html" txp:trim="1" txp:drawboobs="DD">
...contained statement...
</[txp|namespace]:anytag>
Intrigued… can you give an example using an existing tag scenario and demonstrate the benefits?
…smells a bit like something you mentioned back in the xPat days
Offline
Re: <txp:if_yield>
Global pre-processing, e.g. trimming contained statements:
<txp:variable txp:trim="1">
...contained statement with surrounding whitespace....
</txp:variable>Global language-wide post-processing, like encoding strings properly for different contexts. Something you need, but Textpattern doesn’t offer way to do it:
<script>
var excerpt = '<txp:excerpt txp:escape_js="1" />';
</script>Tag and namespace registering and mapping. Just tag namespaces instead of namespaces and prefixes:
bc. <txp:rah_replace from="abc" to="def">
abc
</txp:rah_replace>Versus:
<rah:replace from="abc" to="def">
abc
</rah:replace>Tag names not limited by PHP and collisions:
<txp:file_download_list /> -> function file_download_list()Versus:
<txp:files /> <-> Register() <-> function file_download_list()Offline
Re: <txp:if_yield>
gomedia wrote:
And maybe build in some chh_if_data equivalent functionality too.
That would be something if the templating language was built that in mind. I can’t talk to others, but at least in my opinion that is too risky and conflicting, from both security and bugginess standpoint.
Knowing if something returned something requires execution (as we have it now set up). We don’t have mapped data storage to ask if something has data. Excute -> Condition pattern is wrong way around. Someone will end up using this shorthand condition pattern for security and then wonder why the code still keeps executing.
It would be other thing if we had that pool and could ask tags “hey, do have some some?”. If everyone answers negative, then you don’t execute the block. But, that is not possible. If it does happen (which would be great), it’s in distant future when modernization has already happened.
Offline
Re: <txp:if_yield>
Cool.
- backward compatible?
- would plugins need to be rewritten to take advantage, ie
<rah:replace>vs<txp:rah_replace> - so basically a whole load of existing functionality specific to certain tags is now allowed to exist in any tag via attributes with a “txp:” prefix? (what retooling is required to make this real?)
<mrd:pony txp:request="can haz?" />
Offline
Re: <txp:if_yield>
- Considering you can’t have colons in attribute names and it doesn’t change existing behavior, it’s majorly not compatible.
- I harvested some fairies last time I visited the Tingle Winkle Forest. No kidding. They will travel around the world, posses our old plugin authors and make them update the existing code. So, sure yes. No. Needs at least registering the tag. Changeable namespaces could be option, but causes collision with that thing. What was it called? Umm, something like XML and those other things. Sooo, kinda inclined against having customizable namespaces even that they would be cool. Ruud brought it up first time few years ago, after which it has been in my mind.
- Parser feature. All parser. Some new stuff. I write it here and there. Ready in 2089, around 20 years after I’m gone. Requires like gazillion (some type of horse?) lines of code.
Offline
#18 2012-12-18 19:40:47
- els
- Moderator
- From: The Netherlands
- Registered: 2004-06-06
- Posts: 7,458
Re: <txp:if_yield>
Gocom wrote:
Ready in 2089, around 20 years after I’m gone.
Like the Sagrada Família. You will be famous, Jukka ;)
Offline
Re: <txp:if_yield>
Els wrote:
Gocom wrote:
Ready in 2089, around 20 years after I’m gone.
Like the Sagrada Família. You will be famous, Jukka ;)
Remembered as a coffee machine – the great Jukka5000
Offline
#20 2014-11-16 22:01:40
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: <txp:if_yield>
Offline