Valueless attributes - ELI5 and further reading?

gaekwad · 2016-11-23 15:30:09

I’ve been away from Textpattern development and missed the conversations about valueless attributes.

I’m struggling to get my head around the what these new valueless attributes are about, mostly because in true Textpattern fashion someone here suggested it, someone else said ‘Yes!’, a third person added some extra ideas and by bedtime it was decided, committed and done.

I think they’re helpful to avoid nested tag soup for complex things, but I could be wrong. If they are helpful in avoiding nested tag soup, then I’m definitely interested because I’m like the Head Chef at a 7-star Michelin Restaurant called Chef Cooper’s Soupy Tag Nest Extravaganza and I’m certain the Textpattern parser really dislikes me.

I’d really appreciate some pointers to useful info here (or elsewhere) that covers the gist of how these new inventions work. Examples would also be very appreciated. Thank you very much in advance.

Bloke · 2016-11-23 16:32:28

Its primary use is in allowing a shorter construct for those times when you want to do something if a variable contains something. Take this contrived example, which sets a variable with a comma-space separated list of images if there are any article images:

<txp:variable name="imageList"><txp:if_article_image><txp:images break=", "><txp:image_info type="id" /></txp:images></txp:if_article_image></txp:variable>

Now, further down the page you want to know if you have any images so you can show them. In 4.6:

<txp:if_variable name="imageList" value="">
<txp:else />
   Images used: <txp:variable name="imageList" />
</txp:if_variable>

To do the ‘any’ you need an empty ‘true’ branch. and an else to handle the case when the value is NOT empty. That’s kind of counter-intuitive. Now, from 4.7 onwards you can do this:

<txp:if_variable name="imageList" value>
   Images used: <txp:variable name="imageList" />
</txp:if_variable>

So ‘value’ is correctly equated to true if it contains anything.

Further reading, that got slightly derailed over discussion of negating attributes, but still provides a useful insight.

gaekwad · 2016-11-23 16:40:02

Ah, cool – thanks, Stef. Much obliged.

Not really relevant to my if_* / else tag soup, then. Back to the kitchen for me!

etc · 2016-11-26 23:10:30

gaekwad wrote #302990:

I think they’re helpful to avoid nested tag soup for complex things, but I could be wrong.

Hi Pete,

for my freaky mind they are helpful, though the trick was already possible before. Take this example of yours:

<txp:if_article_list>
	<txp:if_section name="default">
		<txp:if_search>
			<p>is search, default</p>
		<txp:else />	
			<p>is article list, default</p>
		</txp:if_search>
	<txp:else />
		<p>is article list, not default</p>
	</txp:if_section>
<txp:else />
	<p>is individual article</p>
</txp:if_article_list>

You can make it one-liner

<txp:output_form form='list<txp:if_article_list />_default<txp:if_section name="default" />_search<txp:if_search />' />

if you create a form for any possible combination of if_article_list, if_section, if_search. For example, the form list1_default_search must contain

<p>is article list, not default</p>

fwiw

gaekwad · 2016-11-27 14:50:11

Thanks, Oleg. I’m scratching my head with how your one-liner achieves the same thing, but I’ll persevere.

Right now, I’ve extended that if_* mess into a huge chunk of code to cover (what I believe to be) all page states. The verbosity of it isn’t an issue, at least not right now, but I’m very aware of how many checks (queries, and the associated overhead) are undertaken.

Brace yourself. This is what I use for determining the page state to write the <title> in <head>:

<title>
	<txp:if_status status="200">
		<txp:if_individual_article>
			<txp:title />
			<txp:else />
				<txp:if_section name="">
					<txp:if_category>
						Category: <txp:category title="1" />
						<txp:else />
							<txp:if_author>
								Author: <txp:author />
								<txp:else />
									<txp:if_search>
										Search: '<txp:search_term />'
										<txp:else />
											Home
									</txp:if_search>
							</txp:if_author>
					</txp:if_category>   
					<txp:else />
						<txp:if_category>
						Category: <txp:category title="1" /> in <txp:section title="1" />
							<txp:else />
								<txp:if_author>
									Author: <txp:author /> in <txp:section title="1" />
									<txp:else />
										<txp:if_search>
											Search: '<txp:search_term />' in <txp:section title="1" />
											<txp:else />
												<txp:section title="1" />
											</txp:if_variable>
										</txp:if_search>
								</txp:if_author>
						</txp:if_category>   
				</txp:if_section>	
		</txp:if_individual_article>
	</txp:if_status>
	&middot; <txp:site_name />
</title>

Ouch. It works, and it’s raw, but it would be great if I could pare it back. Any advice very warmly welcomed*.

* Please bear in mind you’re far smarter than I, so be gentle.

jakob · 2016-11-27 17:43:11

I’m also trying to wrap my head around Oleg’s example. Does that mean doing the if_* tag as a self-closing tag, i.e.:

_search<txp:if_search />

is the equivalent of doing:

<txp:if_search>_search</txp:if_search>

If so, what delimits the first char of the preceding text? The tag that precedes it (even if that occurs several lines prior)?

@Pete:

That’s an impressive test suite…

To use Oleg’s example for your larger code example – if I’ve understood it correctly –, you’d need to output a form for each situation. That gets unwieldy if you do this for the title, the canonical url and other meta fields.

In such cases I sometimes create a page_vars form that does this testing up-front and defines sets of variables for title, metadata, canonical url, etc. for each if_ situation. While it’s still a lot of if_ statements, it is at least only once for all variables at once. Also, if your desired default output (your fallback value so to speak) corresponds to one of the if_ situations, you can take that as a given and only if_ test for the other situations to override the default value of the variable.
This form is called at the top of the page template and the variables are then plonked into the html head where required. I find it more readable even if the logic is farmed off into a separate form. If you’re worried about the blank space it adds to the html output, you can wrap the whole form in <txp:rah_function call="trim> … </txp:rah_function> which culls the output but keeps the variables.

Other approaches to slimming down vast if_ constructions include:

ascertaining whether all these situations actually occur in your site
utilising txp’s section routing to separate page layout templates. That makes some tests (like search or default section) irrelevant on sub-section page templates.
for certain situations, the little-known rah_meta (Jukka’s second iteration of his earlier rah_metas plugin) or Ruud’s rvm_inherit offer alternative ways of creating a kind of ‘placeholder’ in the html head section that is then populated with the context-specific information from the respective template (or part of the subsequent template logic).

etc · 2016-11-27 21:00:08

jakob wrote #303016:

Does that mean doing the if_* tag as a self-closing tag, i.e.: _search<txp:if_search />... is the equivalent of doing:

<txp:if_search>_search</txp:if_search>...

No, <txp:if_search /> is simply the equivalent of <txp:if_search>1</txp:if_search>. It just saves some typing.

To use Oleg’s example for your larger code example – if I’ve understood it correctly –, you’d need to output a form for each situation. That gets unwieldy if you do this for the title, the canonical url and other meta fields.

Julian has said it all: for such large blocks it’s useless, unless you need to treat all possible combinations. Frankly, if the code verbosity is not an issue, I wouldn’t care about optimizations here. It could be worth optimizing if it were called in a long loop, but this is not the case. All you can save are few bits of memory.

You still can try to make it shorter:

<txp:variable name="in_section" value='<txp:if_section> in <txp:section title /></txp:if_section>' />

<title>
	<txp:if_status status="200">
		<txp:if_individual_article>
			<txp:title />
		<txp:else />
			<txp:if_category>
				Category: <txp:category title /><txp:variable name="in_section" />
			<txp:else />
				<txp:if_author>
					Author: <txp:author /><txp:variable name="in_section" />
				<txp:else />
					<txp:if_search>
						Search: '<txp:search_term />'<txp:variable name="in_section" />
					<txp:else />
						<txp:section title />
					</txp:if_search>
				</txp:if_author>
			</txp:if_category>   
		</txp:if_individual_article>
	</txp:if_status>
	&middot; <txp:site_name />
</title>

etc · 2016-11-27 22:09:25

An amazing construction is

<txp:etc_query markup="raw" query="$strtok($|1).basename"
	data='category<txp:if_category />/author<txp:if_author />/search<txp:if_search />/default1' />

It will output the first of category, author, search tokens (in this order) that is set, or default if none is set. You can use it to call the corresponding form.

Last edited by etc (2016-11-27 22:15:00)

gaekwad · 2016-11-28 10:46:42

jakob wrote #303016:

That’s an impressive test suite…

Thanks! It’s part of the reason I end up breaking the 64kb page size limit so often. The part that deals with AMP delivery is even larger.

To use Oleg’s example for your larger code example – if I’ve understood it correctly –, you’d need to output a form for each situation. That gets unwieldy if you do this for the title, the canonical url and other meta fields.

That was also my interpretation, thanks for the second brain — and thank you for your recommendations, also.

gaekwad · 2016-11-28 10:47:28

etc wrote #303022:

An amazing construction is

<txp:etc_query markup="raw" query="$strtok($|1).basename"...

And this right here is how you’re way smarter than I am. Thumbs up! Thanks!

colak · 2016-11-28 11:15:30

etc wrote #303022:

You can use it to call the corresponding form.

gaekwad wrote #303024:

And this right here is how you’re way smarter than I am. Thumbs up! Thanks!

I’d love to see the final code:)

gaekwad · 2016-11-28 12:51:27

colak wrote #303026:

I’d love to see the final code:)

^{I have to understand it all first…}

Textpattern CMS

Textpattern CMS support forum

#1 2016-11-23 15:30:09