an attribute named "empty"

uli · 2008-06-27 20:32:52

A true jawbreaker, Robert ;)

I think

<txp:variable name="sec" value='<txp:section />' />
<txp:if_variable name="sec" value="products">

is the same as

<txp:if_section name="products" />

Why did you solve it this way? What other ways are there to fill in variables’ values?

The whole variable stuff is rather unseizable for mere mortals without coding background like (Maniqui and) me, as long as we don’t have a clue of what they contain, which vars are accessible (PHP vars also?), when their content can be captured, and when it is disappeared. I’d really appreciate if the variable tags will be documented detailled and all-embracing.

Maniqui, I can really understand your <sup>-comments ;) It just seems that you understood, what I didn’t get. Your sum up helped me a lot, so I now can smartly ask dumb questions ;) and help you a little with this one: In your middle part you mistook txp:variable for txp:section_list. So I think that <txp:if_variable name="sec" value="d">could be achieved with another txp:if_section, right? But right now you’ll have stuffed your mashed brain back where it belongs, so you won’t need this :)

wet · 2008-06-28 05:42:49

maniqui wrote:

<txp:if_variable name=“sec” value=“products”>
<txp:category_list section=“products” categories=“a,b,c” … />
</txp:if_variable></pre>

connected with this
<txp:article_custom section='<txp:section />' category='<txp:category />' ...>
means necessarily that section='<txp:section />' returns section='products' ^{(brain overheating)}

True.

and being that category='<txp:category /> is context sensitive… ^{(brain about to explode)}
mmmm if it returns something different than a, b or c… ^{(sticky chunks of brain all over the walls)}

OK, I can’t connect categories="a,b,c" with category='<txp:category />

Important, new in 4.0.7: <txp:category /> is context sensitive. In the context of processing a <txp:category_list />, it returns the “current” category as indicated by the list. Contrast this with a page context where it returns the category for the current page (i.e. the one dervied from the page’s URL).

categories="a,b,c" is fed into category_list, so category_list produces tree list items. In each single list item <txp:category /> uses the “current” list context, so it returns a for the first list item, b for the second, c for the third in this snippet:

<txp:article_custom section='<txp:section />' category='<txp:category />' ...>

This builds three ULs of permlinks to articles in the products section, one for each of the categories. I could have written this with a literall section name instead of '<txp:section />', but it is expandable to more than one section this way by adding more section names to the driving tag <txp:article_custom section='<txp:section />'

Output:

Products section
- Cars category 'a'
  - Alfa Romeo Mito
  - Volvo C30
  - Fiat Cinquecento
- Planes category 'b'
  - Boeing 777
  - Airbus 350
  - Cessna 172
- Bikes category 'c'
  - Rotwild
  - Schwab
  - You Get The Picture…

<txp:if_variable name=“sec” value=“d”>
<txp:section_list sections=“library” wraptag=“ul” break=“li” />
</txp:if_variable>

I think I didn’t get this one either.
If there is a section named “d”, the condition will be true and then… it will output a txp:section_list but just with the section “library”?
And, at the same time, this section_list is inside the other section_list?

You got it. I admit that this sample wasn’t carefully crafted for educational purposes, but taken from one of my “real life” sites with a somehow slanted nav structure.

Finally: <txp:custom_field name="menutitle" default='<txp:title />' />
Ooooh! I didn’t know about the default attribute for txp:custom_field!
It’s similar to (or exactly) what I’ve asked when I started this thread (an attribute named “empty”)
Just to be sure:
<txp:custom_field name="menutitle" default='<txp:title />' /> is equal to
<txp:if_custom_field name="menutitle"><txp:custom_field name="menutitle"><txp:else /><txp:title /></txp:if_custom_field />
Right?

Perfectly right. I think, this is a simple, yet fine exhibit of attribute parsing and how tight you can code with this new capability.

=

uli wrote:

A true jawbreaker, Robert ;)

I think

<txp:variable name=“sec” value=’<txp:section />’ />
<txp:if_variable name=“sec” value=“products”>

is the same as

<txp:if_section name=“products” />

No, not in this case (New in 4.0.7).

This is taken from the nav2 form, which is the markup template for the first-tier menu driven by a txp:section_list.
NB: It’s the “single item tags” as txp:section and txp:category which are context sensitive, not the corresponding conditional tags (txp:if_category, txp:if_section). Otherwise, you could never test for “active as per the URL” sections, categories in a list.
Result: if_section tests whether the current URL points to products, while txp:section return the current txp:section_list item. The second is what I wanted to achieve with storing the txp:section value in a variable and subsequently test the variables value. txp:variable is used as a “Swiss Army Knife” to pull values from almost any source and use these in a conditional test.

maniqui · 2008-06-28 07:17:10

Just when I was recovering from a broken jaw and an exploded brain… I stepped over wet floor…

wet wrote:

Important, new in 4.0.7: <txp:category /> is context sensitive. In the context of processing a <txp:category_list />, it returns the “current” category as indicated by the list. Contrast this with a page context where it returns the category for the current page (i.e. the one dervied from the page’s URL).

Ok. When in my post I wrote “context sensitive”, I was talking in the now ‘old’ sense of the expression.
If I will try to summary the “sensitive contexts” we already have on 4.0.6 (and previous):

page/url context sensitive for: <txp:section />, <txp:category />
individual-article/article-list context sensitive for: <txp:article />, <txp:section /> (and also, <txp:section /> is “article-form” sensitive, if used inside a form being rendered on an article list, right?)

Now (4.0.7), we also have, this new “sensitive” context:

tag context sensitive: <txp:section />, <txp:category /> (very similar to the “article-form” context sensitive I listed above for <txp:section />)

Am I going well? I hope.
But… (yes, wet already stated, the example wasn’t carefully crafted for educational purposes)

wet wrote:

<txp:article_custom section='<txp:section />' category='<txp:category />' ...>

This builds three ULs of permlinks to articles in the products section, one for each of the categories. I could have written this with a literall section name instead of '<txp:section />', but it is expandable to more than one section this way by adding more section names to the driving tag <txp:article_custom section='<txp:section />'

If <txp:section /> now is tag context sensitive, I may have spotted a mistake in wet’s explanation above, or I may not have understand him. Let’s see.

First question/thing-to-notice: look the code above (<txp:article_custom section='<txp:section />' ...>).
There, section='<txp:section />' is being page/url sensitive or tag-context sensitive?
If I get it right, there, txp:section is being tag-context sensitive.

But wet explained: “but it is expandable to more than one section this way by adding more section names to the driving tag <txp:article_custom section='<txp:section />'”

There is where I think I spotted an error in the explanation:
Isn’t the driving tag this one: <txp:category_list section="products" categories="a,b,c" ... />? If not, then I don’t get it yet :)
But if indeed it is the driving tag, wet said:
“is expandable to more than one section this way by adding more section names”

Is that last statement correct? If yes, then I get that section attribute on <txp:category_list /> can receive more than one value. Like this:
<txp:category_list section="products, library, support">

But does that last one work/make-sense? Only if now <txp:category_list /> can also iterate over values for section (singular) attribute.

Output […]

Nice! And putting the output made everything clearer.

New in 4.0.7

NB: It’s the “single item tags” as txp:section and txp:category which are context sensitive, not the corresponding conditional tags (txp:if_category, txp:if_section). Otherwise, you could never test for “active as per the URL” sections, categories in a list.

Result: if_section tests whether the current URL points to products, while txp:section return the current txp:section_list item. The second is what I wanted to achieve with storing the txp:section value in a variable and subsequently test the variables value. txp:variable is used as a “Swiss Army Knife” to pull values from almost any source and use these in a conditional test.

Great. This explanation worked better for me.
I suggest again to create some “official” nomenclature for naming different “context sensitive” possibilites.
As I suggested above, some names that make sense for me:

page/url context sensitive
individual-article/article-list context sensitive
tag context sensitive (the new one on 4.0.7)

BTW, many thanks, wet!!!

Last edited by maniqui (2008-08-16 22:54:33)

maniqui · 2008-06-28 07:25:08

uli wrote:

The whole variable stuff is rather unseizable for mere mortals without coding background like (Maniqui and) me

Not sure what “unseizable” means, but yes, we play on the same league (that of those who don’t know what PHP stands for)! :)
I’m trying (hard, and at the same time not that hard, but trying at least) to learn programming, reading a little of Python (that’s the one that we use at work), looking to JS/jQuery code, but I can’t hear the “click” on my head yet. It’s like I have to re-learn everything each time. I know: I have to practice, practice, practice… but can’t find some real situations to do it and so, solidify what I’ve learned.
In the meanwhile, let’s learn to “program” in TXP ;)

wet · 2008-06-28 07:26:59

maniqui wrote:

There is where I think I spotted an error in the explanation:
Isn’t the driving tag this one: <txp:category_list section="products" categories="a,b,c" ... />? If not, then I don’t get it yet :)
But if indeed it is the driving tag, wet said:
“is expandable to more than one section this way by adding more section names”

Is that last statement correct?

No, I was terribly wrong with that (early morning here). Forget this part, pronto!

maniqui · 2008-06-28 07:44:29

wet wrote:

Forget this part, pronto!

Forget what? ;)

Bloke · 2008-06-28 08:20:08

Some good example usage in there wet, thanks. Definite food for thought on ways to write rather neat navigation structures.

Slightly OT, but related to the original thing that Els/colak suggested; in the absence of a built-in tag that checks if the enclosed tag(s) returned anything, would it be possible to add an FAQ entry to the effect:

TXP does not have a native method for checking if a tag returned output or not, but there is a plugin chh_if_data

fwiw, the only way I can (could) have seen to leverage <txp:variable /> for this kind of thing would be thus:

<txp:variable name="did_it" value='<txp:related_articles match="Category1" />' />
<txp:if_variable name="did_it" value="">
  <txp:related_articles break="li" label="Related Articles" labeltag="h3" limit="5" match="Category1" sort="rand()" wraptag="ul" />
</txp:else />
  <p>No related articles, sorry.</p>
</txp:if_variable>

But under the latest behaviour you can’t check for an “empty” variable (one with no value) since it is erased if the value is empty. Does (or could?) the <txp:if_variable name="some_name" /> — i.e. the tag without a value — test for the existence of said variable? Then the above scenario might be possible without the chh_if_data plugin.

Of course, it’s still borderline undesirable because you need two calls to the same(ish) tag — one to ‘check’ and one to ‘do’ — which will slow the page down. I still think a native “did the contained tag(s) return anything” tag adds value to the core. But perhaps I’m not thinking hard enough about this new tag and the tag-in-tag possibilities.

Last edited by Bloke (2008-06-28 08:20:45)

wet · 2008-06-28 08:40:39

Bloke wrote:

Does (or could?) the <txp:if_variable name="some_name" /> — i.e. the tag without a value — test for the existence of said variable?

Intended behaviour is:

<txp:variable name="foo" /> returns the variable’s value.
<txp:variable name="foo" value="" /> erases the variable’s value. The variable still exists, though empty.
<txp:variable name="foo" value="bar" /> sets the variable’s value. Basically this is the same as #2.
<txp:if_variable name="foo"> tests for the existence.
<txp:if_variable name="foo" value="bar"> tests for the value, and therefore also for the existence.

If your tests show that we deviate from this intentions, we need to fix it.

Of course, it’s still borderline undesirable because you need two calls to the same(ish) tag — one to ‘check’ and one to ‘do’ — which will slow the page down.

I don’t think this is 100 percent relevant. Skimming over chh_if_data shows that it parses the contained $thing (it has to), and therefore it ‘does’ & ‘checks’ internally. This might speed things up a little bit, but the difference would probably be minimal (someone might want to do a benchmark on this – not me).

Last edited by wet (2008-06-28 08:47:41)

Bloke · 2008-06-28 08:51:08

wet wrote:

Intended behaviour is: [snip]

OK, cool, perfect.

Skimming over chh_if_data shows that it parses the contained $thing (it has to), and therefore it ‘does’ & ‘checks’ internally.

D’oh, of course. So the above thing I posted will work. Eeexcellent, as Mr Burns would say.

I’ll crawl back in my box now.

thebombsite · 2008-06-28 09:35:49

You remember that “learning curve” you went through when you first installed Textpattern? Well it seems to me that 4.0.7 is going to be deja vu. ;)

wet · 2008-06-28 09:39:29

People are complaining no matter what we do ;-)

Conservative development: “The project dies!”
Slightly progressive development: “Steep learing curve ahead!”

uli · 2008-06-28 11:20:42

Julián wrote:

but I can’t hear the “click” on my head yet. It’s like I have to re-learn everything each time.

I can find myself herein very well!!

In the meanwhile, let’s learn to “program” in TXP ;)

Yeah! It’s seems to become something like that. Devs, release it as 4.1, my proposal. Opens too many doors to give just one tenth of a decimal place!
“Unseizeable”, BTW, if I used it correctly, should express something like “too theoretical, not graspable”.

Stuart wrote:

You remember that “learning curve” you went through when you first installed Textpattern? Well it seems to me that 4.0.7 is going to be deja vu. ;)

Yup! Gives us stuff enough to mull over. Rust never sleeps, here’s our antidote. Just don’t eat the whole packet at once ;)

Last edited by uli (2008-06-28 11:21:28)

Textpattern CMS

Textpattern CMS support forum

#13 2008-06-27 20:32:52

Re: an attribute named "empty"

#14 2008-06-28 05:42:49

Re: an attribute named "empty"

#15 2008-06-28 07:17:10

Re: an attribute named "empty"

#16 2008-06-28 07:25:08

Re: an attribute named "empty"

#17 2008-06-28 07:26:59

Re: an attribute named "empty"

#18 2008-06-28 07:44:29

Re: an attribute named "empty"

#19 2008-06-28 08:20:08

Re: an attribute named "empty"

#20 2008-06-28 08:40:39

Re: an attribute named "empty"

#21 2008-06-28 08:51:08

Re: an attribute named "empty"

#22 2008-06-28 09:35:49

Re: an attribute named "empty"

#23 2008-06-28 09:39:29

Re: an attribute named "empty"

#24 2008-06-28 11:20:42

Re: an attribute named "empty"

Board footer