Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
<txp:if_yield>
1. That you think about new tag <txp:if_yield>
?
<txp:if_yield> ... yield present </txp:if_yield>
<txp:if_yield value="some"> ... </txp:if_yield>
.
2. Maybe need extend <txp:output_form />
tag with yield
attribute?
<txp:output_form form="someform" yield="somevariable" />
.
3. Crazzy idea: send unlimited variables to <txp:output_form />
<txp:output_form form="someform" anyname1="somevariable" anyname2="qwerty" />
someform:
<txp:yield name="anyname1" /> <txp:yield name="anyname2" /> <txp:if_yield name="anyname1"> .. <txp:else /> .. </txp:if_yield> <txp:if_yield name="anyname2" value="qwerty"> .. </txp:if_yield>
aks_cron : Cron inside Textpattern | aks_article : extended article_custom tag
aks_cache : cache for TxP | aks_dragdrop : Drag&Drop categories (article, link, image, file)
Offline
Re: <txp:if_yield>
Hi makss
Nice to see someone has the same ideas I have. (I’m not saying this ideas are good ;) )
Regarding idea 1 (txp:if_yield
), although it could be a nice shortcut, it can definitely be done with txp:variable
and txp:if_variable
. And, if you need more complicated testing of txp:yield
value, there is always Stef’s smd_if
.
The disadvantage of the txp:variable/txp:if_variable
method is that you will be creating a global variable, while the yield is scoped to the form. smd_if
overcomes that problem.
Regaridng idea 2 (yield=""
attribute), it also looks just as a shortcut/alternative/sugar-syntax, and I don’t think it adds anything new but… I like it as it avoids the extra closing tag. Particularly useful if the yielded thing is just a string.
Most times, I use the yield to pass some string(s) to the form and then evaluate the string (with smd_if or smd_multi_choice) and do crazy stuff. I should write a tip about this trick, as it’s particularly useful when wrapping a txp:output_form
with txp:article
(or txp:article_custom
), making it really easy to manage some related article forms inside just one form.
Regarding idea 3 (send unlimited/on-the-fly variables from txp:output_form
). I really ilke too, and in fact, it’s one feature I was going to request too. Even more, I’ve requested something similar in the past: “named yields”.
I would add that this variables should be scoped to the form. Similarly to how the yield works: it just works inside the form, and then gets destroyed.
makss: you may find interesting reading this thread about txp:yield
, its usage, and some ideas/request discussed about it.
artagesw (txp developer) talks about a hypothetical txp:scope
core tag, a bit overcomplicated imho, that could add a similar functionality to what you (and I) are asking for.
Last edited by maniqui (2010-06-26 21:52:42)
Offline
Re: <txp:if_yield>
maniqui wrote:
Nice to see someone has the same ideas I have. (I’m not saying this ideas are good ;) )
:)
Regarding idea 1 (txp:if_yield
), now I use txp:variable/txp:if_variable
for it.
Regaridng idea 2 (yield=""
attribute), YES, this is only simple syntax.
Regarding idea 3 (send unlimited/on-the-fly variables from
txp:output_form
). I really ilke too, and in fact, it’s one feature I was going to request too. Even more, I’ve requested something similar in the past: “named yields”.
I would add that this variables should be scoped to the form. Similarly to how the yield works: it just works inside the form, and then gets destroyed.
I agree with everything :)
<txp:output_form form="someform" anyname1="somevariable" anyname2="qwerty" >some text</output_form>
In form
<txp:php>print_r($yield);</txp:php>
Output this:
$yield['anyname1']="somevariable" $yield['anyname2']="qwerty" $yield['yield']="some text"
aks_cron : Cron inside Textpattern | aks_article : extended article_custom tag
aks_cache : cache for TxP | aks_dragdrop : Drag&Drop categories (article, link, image, file)
Offline
Re: <txp:if_yield>
makks – idea with sending data via output_form attrs sound great! At current point i cann’t imaging where to use this ability, but sounds great :)
Providing help in hacking ATM! Come to courses and don’t forget to bring us notebook and hammer! What for notebook? What a kind of hacker you are without notebok?
Offline
#5 2010-06-27 01:10:46
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: <txp:if_yield>
makss wrote:
new tag
<txp:if_yield>
?
Get’s my vote. Most other TXP tags are iffy these days, so why not txp:yield
too? They all help improve the readability of TXP source code.
Offline
Re: <txp:if_yield>
Just thought to have if_yield and found this thread. vote for this and for:
<txp:if_yield value="lalala">
Providing help in hacking ATM! Come to courses and don’t forget to bring us notebook and hammer! What for notebook? What a kind of hacker you are without notebok?
Offline
#7 2012-12-16 22:25:31
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: <txp:if_yield>
Proposal for new if_yield tag submitted
Offline
Re: <txp:if_yield>
Thank you for the proposal. It will likely see the day of light in any day now. But the trim, I will be straight with you and say that the trim attribute will not happen on a tag level. If it ever happens, it will be implemented as a language wide, namespaced attribute. Something that is handled by the parser itself.
The worst thing that could ever happen is to have inconsistent attributes, or 350 instances of duplicated code which then most plugin tags won’t even have implemented. Inconsistent attributes and tag naming is something we already have and do not need more.
Offline
#9 2012-12-16 23:43:35
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: <txp:if_yield>
Thanks for the reply, I look forward to seeing the official update.
Whitespace is a constant issue when it comes to testing content. As soon as you lay out code on separate lines and/or with indents, it’s game over. Is there some other built-in mechanism that could be implemented? <txp:trim>...</txp:trim>
? Yes I know there’s rah_function call="trim"
but it’s a real shame TXP makes us fight to do some of the basic stuff.
Offline
Re: <txp:if_yield>
r5074 introduces if_yield tag. The tag can be used inside forms fetched with output_form. As a conditional, It holds identical feature set to if_variable, minus the name
attribute.
Checking if the yield is defined:
<txp:if_yield>
Output_form was used as a container.
<txp:else />
No yield defined.
</txp:if_yield>
Comparing against empty:
<txp:if_yield value="">
No yield, is empty.
<txp:else />
Yield set: <txp:yield />
</txp:if_yield>
Or against a specific value:
<txp:if_yield value="red">
Yield is red.
</txp:if_yield>
gomedia wrote:
Is there some other built-in mechanism that could be implemented?
Wind back few seconds:
If it ever happens, it will be implemented as a language wide, namespaced attribute. Something that is handled by the parser itself.
E.g.
<[txp|namespace]:anytag txp:encode="html" txp:trim="1" txp:drawboobs="DD">
...contained statement...
</[txp|namespace]:anytag>
Long term end goal for me would have tag registering, code base automation (in terms tag reflector classes, storages) and parser features, including namespaces for both tags and attributes. In process bringing in consistent tag naming (file_download_list vs. images, eh) and attribute set.
Offline
Re: <txp:if_yield>
Adi, thanks for that if_yield Christmas present :)
(Jukka) Inconsistent attributes and tag naming is something we already have and do not need more.
+1
Regarding white space, double spaces, etc.: What about an extra good old/new txp:compress
run for the HTML output? There all the compress attributes could be defined.
Eg. before storing an article or sending page output to the web server?
Even CSS could be optimized before storage.
Get all online mentions of Textpattern via OPML subscription: TXP Info Sources: Textpattern RSS feeds as dynamic OPML
Offline
#12 2012-12-18 00:32:14
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: <txp:if_yield>
Gocom wrote:
r5074 introduces if_yield tag. The tag can be used inside forms fetched with output_form. As a conditional, It holds identical feature set to if_variable, minus the
name
attribute.
Thanks.
Long term end goal for me would have tag registering, code base automation (in terms tag reflector classes, storages) and parser features, including namespaces for both tags and attributes. In process bringing in consistent tag naming (file_download_list vs. images, eh) and attribute set.
Roll on the “Long term end goal”. And maybe build in some chh_if_data equivalent functionality too.
Offline