Making nested lists

etc · 2021-03-09 15:36:09

Bloke wrote #329177:

This is compounded by <txp:if_first_link> only firing on the first link of the entire tag, not the first link of each category, since breakby can’t be used to divert to a breakform.

Wouldn’t this suffice? You only need it to avoid inserting a lonely </dl> (untested):

<txp:linklist category='<txp:variable name="reading-cats" />' sort="category" wrapform="linkgroup">
<txp:if_different test='<txp:link_category />'>
    <txp:if_first_link not></dl></txp:if_first_link>
    <h4><txp:link_category title /></h4>
    <dl>
</txp:if_different>
        <dt><txp:linkdesctitle /></dt>
        <dd><txp:link_description /></dd>
    <txp:if_last_link></dl></txp:if_last_link>
</txp:linklist>

Bloke · 2021-03-09 15:42:30

etc wrote #329179:

Wouldn’t this suffice?

Yes!

    <txp:variable name="reading-cats">
        <category::list type="link" parent="further-reading" break="," trim>
            <txp:category />
        </category::list>
    </txp:variable>

    <txp:linklist category='<txp:variable name="reading-cats" />' sort="category" label="Further reading" labeltag="h3">
        <if::different test='<txp:link_category />'>
            <if::first_link not></dl></if::first_link>
            <link::category title wraptag="h4" />
            <dl>
        </if::different>
            <dt><txp:linkdesctitle /></dt>
            <dd><link::description /></dd>
        <if::last_link></dl></if::last_link>
    </txp:linklist>

That is more performant (fewer queries) even if it is slightly more labour intensive.

EDIT: 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*.

Thank you!

Last edited by Bloke (2021-03-09 15:47:39)

etc · 2021-03-10 15:08:46

Bloke wrote #329178:

Looking forward to the day this can be done in line with the superior attributes that article/category list tags support.

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

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?

Textpattern CMS

Textpattern CMS support forum

#13 2021-03-09 15:36:09

Re: Making nested lists

Bloke wrote #329177:

#14 2021-03-09 15:42:30

Re: Making nested lists

etc wrote #329179:

#15 2021-03-10 15:08:46

Re: Making nested lists

Bloke wrote #329178:

#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

Board footer