Making nested lists

jakob · 2021-03-10 16:05:33

etc wrote #329194:

It looks rather easy to modularize doArticles() and reuse the code for other lists. There is just override_form that is specific to articles.

I love the sound of that idea. I’m not sure if I’m imagining too much here, but I’ve long harboured the desire to have a way of applying the various article-related tags to other tables with a similar structure. It would completely obviate the need to replicate tags for if_first / if_last / if_different / filtering and pagination if one could pass the table to the function. Plugins for own content-types could hook into those without providing numerous duplicate functions.

Bloke · 2021-03-10 16:32:29

etc wrote #329194:

It looks rather easy to modularize doArticles() and reuse the code for other lists.

*drools*

You fancy experimenting with a doContent() (or whatever) function and then getting the other specific content tags to call it? Or, if you’re feeling flush and we can keep performance up, a new Content class from which the various subtypes are derived?

There is just override_form that is specific to articles.

Would it be terrible if we could, y’know, extend the concept of override form to all content types? Seems like a winner to me, especially since we can now choose which types are permitted.

The downside is that you’d have to (at present) choose a set of override forms available to all content types from prefs; you couldn’t use a couple of Form groups for Articles and a different group for Links, for example. That could be changed if we extended the idea to all content types (though the settings might be fun from a UX viewpoint, so we’d need to think about that).

But off the top of my head I can’t see a downside to allowing individual images, files or links to override the form specified in the template. Might be quite handy. Not sure how it would affect our ‘in use’ indicators on the Forms panel and the corresponding multi-edit.

Any downsides, anyone?

jakob wrote #329195:

It would completely obviate the need to replicate tags for if_first / if_last / if_different / filtering and pagination if one could pass the table to the function.

Yeah this is kinda what I was alluding to above: <if::first type="link">...</if::first>. Bonus points, as you say, if plugins could hook into them for their own list-type tables. Wow!

Last edited by Bloke (2021-03-10 16:37:37)

etc · 2021-03-10 17:25:36

jakob wrote #329195:

I’ve long harboured the desire to have a way of applying the various article-related tags to other tables with a similar structure. It would completely obviate the need to replicate tags for if_first / if_last / if_different / filtering and pagination if one could pass the table to the function. Plugins for own content-types could hook into those without providing numerous duplicate functions.

There is another possibility: consider and store all content types (images, links, custom) as ‘articles’, with proper cf set. Then they would get all articles functionality for free.

Bloke wrote #329196:

You fancy experimenting with a doContent() (or whatever) function and then getting the other specific content tags to call it? Or, if you’re feeling flush and we can keep performance up, a new Content class from which the various subtypes are derived?

A least resistance way, if we want to release 4.8.5 :-) Also because things could change yet in cf branch.

Would it be terrible if we could, y’know, extend the concept of override form to all content types? Seems like a winner to me, especially since we can now choose which types are permitted.

Currently it means adding override_form to their tables and admin tabs. Just imagine getting all this for free if everything were ‘article’…

gaekwad · 2021-03-11 10:14:10

Bloke wrote #329180:

Note that, annoyingly due to lack of underscores, the <txp:linkdesctitle> tag can’t use shorthand syntax where most other things bar linklist can. grumbles at silly, inconsistent naming convention of tags.

Have a word with the management.

Bloke · 2021-03-19 09:45:19

Forgot to follow up on this. The new breakby / breakform superheroes in 4.8.5 now allow this construction for linklists and, indeed, any list-style tags:

<!-- Get a list of categories from the tree under a given parent -->
<txp:variable name="reading-cats">
    <category::list type="link" parent="further-reading" break="," trim>
        <txp:category />
    </category::list>
</txp:variable>

<!-- Loop over the above categories and split them by category heading. -->
<!-- Note the double quotes around the breakby attribute as we want the
     tag to be processed when it's in context -->
<txp:linklist category='<txp:variable name="reading-cats" />' sort="category" label="Further reading" labeltag="h2" breakby="<link::category />" breakform="linkgroup">
    <li><txp:linkdesctitle />
    <txp:evaluate><br/><link::description /></txp:evaluate></li>
</txp:linklist>

With the linkgroup form containing this:

<link::category title wraptag="h3" />
<ul><+></ul>

This makes the creation of nested lists, tables, etc so much simpler. Fabulous stuff!

etc · 2021-03-19 10:58:47

Nice! You can even spare few extra bits:

<link::description wraptag="<br /><+>" />

Bloke · 2021-03-19 11:12:53

Oooh, even better! No need for the evaluate wrapper in that instance. Thank you.

Destry · 2024-01-10 12:08:37

Thanks for sharing this, Bloke. It’s just what I needed (I went with the definition lists). I would not have figured it out.

Destry · 2024-01-11 12:52:56

I want to output a category description for each nested category of links. It would appear here when viewed on the front side:

<link::category title="1" wraptag="h2" />
{link category description}
<dl><+></dl>

I tried this, if I understand the value attribute correctly, but the description being output is the links section description, repeating in each case. I would expect seeing the individual descriptions for each link category in nested output. There’s probably a context issue I’m overlooking?

<link::category title="1" wraptag="h2" />
  <txp:if_description>
    <p><txp:meta_description format="" value="category.link" /></p>
  </txp:if_description>
<dl><+></dl>

Maybe I’m using the meta_decription tag in the wrong place?

etc · 2024-01-11 13:05:45

I think it’s type, not value. You should also remove if_description here, in favour of wraptag="p". Or pass it type too, but this would be a waist of cycles.

And even this will not work, looking at the code.

Destry · 2024-01-11 13:19:06

I adjusted to this:

<link::category title="1" wraptag="h2" />
<p><txp:meta_description format="" type="category" /></p>
<dl><+></dl>

That did make the section description go away, but there is no output for category descriptions. Same difference if using type="category.link", if that matters.

Am I supposed to be adding something to the variable, and passing it along? (Says the guy who knows not of what he speaks.)

etc · 2024-01-11 13:22:31

That’s what you could try instead:

<txp:category_list categories='<link::category />' type="link">
    <txp:category title="1" wraptag="h2" />
    <txp:meta_description format="" wraptag="p" />
</txp:category_list>

Destry · 2024-01-11 13:23:13

To be thorough, here’s what’s in the Links page template:

<txp:variable name="good-sites">
    <category::list type="link" parent="looming-future" sort="name asc" break="," trim>
        <txp:category />
    </category::list>
</txp:variable>

<txp:linklist category='<txp:variable name="good-sites" />' sort="category" breakby="<link::category />" breakform="linkgroup">
    <dt><a href="<txp:link_url />" rel="external"><txp:link_name /></a></dt>
    <dd><link::description /></dd>
</txp:linklist>

And this in the links form:

<link::category title="1" wraptag="h2" />
<p><txp:meta_description format="" type="category" /></p>
<dl><+></dl>

It all works okay except I’m not getting this output as expected for each category label above it:

<p><txp:meta_description format="" type="category" /></p>

Edit: you beat me to the punch

Last edited by Destry (2024-01-11 13:23:42)

Bloke · 2024-01-11 13:26:09

I was about to say that in order to output category information you need to be in some category context (some wrapper or URL scheme that triggers it). But Oleg beat me to it too.

Destry · 2024-01-11 13:26:37

etc wrote #336358:

That’s what you could try instead

Bingo. Thank you.

Textpattern CMS

Textpattern CMS support forum

#16 2021-03-10 16:05:33

Re: Making nested lists

etc wrote #329194:

#17 2021-03-10 16:32:29

Re: Making nested lists

etc wrote #329194:

jakob wrote #329195:

#18 2021-03-10 17:25:36

Re: Making nested lists

jakob wrote #329195:

Bloke wrote #329196:

#19 2021-03-11 10:14:10

Re: Making nested lists

Bloke wrote #329180:

#20 2021-03-19 09:45:19

Re: Making nested lists

#21 2021-03-19 10:58:47

Re: Making nested lists

#22 2021-03-19 11:12:53

Re: Making nested lists

#23 2024-01-10 12:08:37

Re: Making nested lists

#24 2024-01-11 12:52:56

Re: Making nested lists

#25 2024-01-11 13:05:45

Re: Making nested lists

#26 2024-01-11 13:19:06

Re: Making nested lists

#27 2024-01-11 13:22:31

Re: Making nested lists

#28 2024-01-11 13:23:13

Re: Making nested lists

#29 2024-01-11 13:26:09

Re: Making nested lists

#30 2024-01-11 13:26:37

Re: Making nested lists

etc wrote #336358:

Board footer