Glossary architecture

Bloke · 2022-06-05 07:22:54

The evaluate tag in that form just takes the first letter of the article title (after sticking apostrophe quotes round it) and then uppercases it.

etc · 2022-06-05 08:50:05

Bloke wrote #333528:

The evaluate tag in that form just takes the first letter of the article title (after sticking apostrophe quotes round it) and then uppercases it.

This can be done in a more straightforward way now (4.8.8):

<txp:title breakby="" limit="1" escape="upper" />

There is more 4.8 magic to employ, to make the used category list construction automatic. A good txp exercise it is.

Destry · 2022-06-05 13:15:35

Okay, I’ll study that a bit.

Now is a good time to slide in the next phase of thinking…

What bugs me about the CMS glossary I was basing on: if a person doesn’t know the name of a tool (or whatever other group)—and they may not if just beginning, or the tool has a foreign name—then filtering by alphabet letter is kind of useless.

More useful would be topic filters, and I have 6 in mind as first-level filters, which kind of represent the eventual totality of the glossary (though the amount of writing between now and 6 fleshed-out topic domains is light years away):

image: Glossary Topics filters

That by itself is kind of nifty. The letter categories (A, B, C, …) still exist, and when a topic cat is clicked, it filters the glossary holdings to show only entries related to that topic, but still in the alphabetial structure. Not bad. I could live with that for a while as the glossary fills out, but…

I have now used up the 2-category limit per article, and some of the first-level topic categories (tools, trees, timber, …) could in fact be refined with second-level filter terms. There are different ways to sub-group ‘Tools’, for example, but this one is an easy demonstration: Tools [Adzes, Axes, Chisels, Gouges, Planes, Saws, Squares, ...]. The idea being, if you click Tools, say, then two things happen: 1) the terms filter as expected. 2) A new line of sub-terms appear under the parent term to further drill down.

In other words, you have a tags tree developing, and categories alone seemingly go out the window.

This begs the questions:

Is there going to be unlimited categories in relation to unlimited custom fields? (Can’t remember the goal there.)
Or does this supposed hierarchy now require bringing in smd_tags?¹
If so, can the neat idea above be retained; that is, where for each cat or tag you click in the filtering list, the relevant articles will sort underneath by the nice alphabetized blocks in relation?

If 2 and 3 are yes and yes, then I will install and tag-a-thon as first step, and see where I get with the refactoring.

^{1. This would be a critical plugin, in that case, which I would never be able to maintain, if necessary. Wet once told me everyone should have an exit plan (and asked me what was mine). I found it rather sage advice, and an important notion in one’s permacomputing planning. I’m always curious if everyone does have such a plan, but it’s in the front of my thoughts for myself, especially lately as I try to minimize the things in my life, real and esoteric. So, no offense intended, here, but is there at least a 5-year reliability on such a plugin? Rhetorical. :}}

Last edited by Destry (2022-06-05 15:59:10)

Bloke · 2022-06-05 14:56:33

Y’know, I don’t think you need the category1 for the first letter of the title. It’s kind of wasted effort because you know the first letter of the title: it’s the first letter of the article which is easily obtainable as a list. Something like this (untested) :

<article::custom limit="0" section="glossary-detail" sort="UPPER(Title)">
<txp:variable name="currlet"><txp:title breakby="" limit="1" escape="upper" /></txp:variable>
   <if::different>
      <a href="<txp:site_url />glossary/display/<txp:variable name="currlet" />"><txp:variable name="currlet" /></a>
   </if::different>
</article::custom>

It iterates over all articles in the given section and spits out the next hyperlinked letter if it exists.

The hyperlinks themselves are to an article called display (or it could be to your Page template code if you don’t mind the ‘page does not contain an article’ warning popping up) inside which you can use the power of <txp:page_url /> to extract the bit of the URL after the article title. e.g. type="3" to get the third parameter. In this case it’d be the letter that’s been clicked. Then in your article/page code, you can iterate over all articles again with another article_custom tag to display a list of all articles that start with that letter.

It’s not as efficient, because it has to iterate over all articles to get the list of letters, and then iterate over them all again to match against the selected starting letter. But it does save a category, which means you can use it to slice and dice your content in other ways.

I think that kind of approach would work. Not tried it. Matching the letter after click might be interesting as we can’t use article_custom to filter that directly (unless we can use the new fields attribute somehow).

Failing that, yes, smd_tags will do it. And even generate the tag list and ‘first letter’ cloud for you. There’s an example in the plugin docs to do precisely that.

Last edited by Bloke (2022-06-05 15:05:39)

Bloke · 2022-06-05 14:59:37

P.S. in terms of unlimited categories, current thinking is to just hijack article Keywords and repurpose them as a list of ‘tags’ (aka categories).

Keywords are currently useless, as they were originally intended, due to browser and search engine behaviour changes in the wake of spam, so it’s arguably just going begging. If we can retool them to be more useful then we get unlimited categories… sort of…. for free, without the major database upheaval that reengineering true unlimited categories would bring.

Destry · 2022-06-05 16:04:31

Bloke wrote #333531:

Y’know, I don’t think you need the category1 for the first letter of the title.

You have my attention. I extra category might be just enough. I can live with the extra loop; or I should say, readers can.

Failing that, yes, smd_tags will do it. And even generate the tag list and ‘first letter’ cloud for you. There’s an example in the plugin docs to do precisely that.

Perfecto.

Who knows, maybe tags will be native one day. I mean, hey, themes happened. :}

etc · 2022-06-06 08:46:55

Bloke wrote #333531:

It’s not as efficient, because it has to iterate over all articles to get the list of letters, and then iterate over them all again to match against the selected starting letter.

On Default page, the efficiency can be improved by altering the processing order:

<!-- this tag will be processed last -->
<txp:variable[-1] name="menu" />
...
<txp:article_custom>
<!-- Output the titles and add new letter links to "menu" variable -->
</txp:article_custom>

Matching the letter after click might be interesting as we can’t use article_custom to filter that directly (unless we can use the new fields attribute somehow).

IIRC, we can filter articles by url_title now, which usually matches the ‘true’ title?

But I may be late to the party, it looks like you are already on the next iteration.

Bloke · 2022-06-06 10:44:55

etc wrote #333535:

we can filter articles by url_title now, which usually matches the ‘true’ title?

Of course, doh! Nice trick. That would definitely work in this case.

Nice workaround for the processing order too. Neat

jakob · 2022-06-06 16:08:37

etc wrote #333529:

This can be done in a more straightforward way now (4.8.8):

<txp:title breakby="" limit="1" escape="upper" />

This is new to me! Does that mean iterate over the output of title and breakby each character (as no breakby string is provided). Without a breakform, it just outputs the content as-is.

Can we use this to iterate over almost anything by providing a string or character to breakby? A bit like rah_repeat or smd_each?

And can we use this with any tag, not just the iteration tags? Currently breakby is only listed for certain tags.

etc wrote #333535:

<!-- this tag will be processed last -->
<txp:variable[-1] name="menu" />

Cool! This one is also new to me but looks potentially extremely useful!

Does that work everywhere? It feels a bit like using <txp:hide process="2">… tags … </txp:hide>. A really common situation that was once catered for by arc_meta / rah_meta is putting details from an article on the page in the html head. In-page menus (a bit like this situation) could be another useful case.

Destry · 2022-06-06 17:34:42

@Jakob,

At least you understand the potential of these things. I’m like, ‘at what page in the manual do I need to start reading to get these nuts and bolts in order?’ I guess attributes is probably the answer to that.

Sometimes I think bagging this glossary is the smarter move. Hundreds of hours of time, and back-of-the-mind worry, would be saved by the end of it. If I didn’t like the writing part so much, it would be an easy decision.

But, as Oleg said, ‘a good txp exercise it is.’ The glossary will be my last Txp site; le dernier tableau de l’œuvre de Wion.

etc · 2022-06-07 09:32:06

jakob wrote #333539:

<txp:title breakby="" limit="1" escape="upper" />...

Does that mean iterate over the output of title and breakby each character (as no breakby string is provided). Without a breakform, it just outputs the content as-is.

Can we use this to iterate over almost anything by providing a string or character to breakby? A bit like rah_repeat or smd_each?

And can we use this with any tag, not just the iteration tags?

Yes to all. In 4.8.8 breakby, as well as break, limit, offset and sort, have become truly global. This means that

the tags that already had these attributes (manly listing tags) continue to work as before.
for other tags, these attributes are applied to the output, splitting/sorting/extracting/joining it again.
if you provide a breakform, the items are available via <txp:yield item /> therein.

For example,

<txp:variable name="test" value="13, 5, 8, 3" breakby limit="2" sort="nat desc" break="+" output />

will store and output 13+8 which you could plug into <txp:evaluate /> to calculate the sum of two greatest values.

...

Does that work everywhere? It feels a bit like using <txp:hide process="2">… tags … </txp:hide>.

Yes, but it’s more powerful than <txp:hide />, since

it does not require second/extra parser passes (which still makes me thrill security-wise)
it can simulate as many passes as you need, completely changing the processing order.

The only restriction is that the order is altered on siblings level, not absolutely, but that’s how txp works.

jakob · 2022-10-13 20:12:59

etc wrote #333535:

<!-- this tag will be processed last -->
<txp:variable[-1] name="menu" />

etc wrote #333541:

Yes, but it’s more powerful than <txp:hide />, since

it does not require second/extra parser passes (which still makes me thrill security-wise)

it can simulate as many passes as you need, completely changing the processing order.

The only restriction is that the order is altered on siblings level, not absolutely, but that’s how txp works.

I’d love to properly understand this. I came up against a situation today where I’d like to optionally output something from an article before the txp:article(_custom) tag has been called.

I tried this:

<txp:variable[-1] name="item_from_article" wraptag="h2" class="my-class" />
…
<txp:article form="article_single" listform="article_single" limit="1" />

and then in the article_single form, the variable is defined as:

<txp:variable name="item_from_article" output><txp:title /></txp:variable>

(The page is a landing page, so article_single is being called as the listform).

I get no output from that, but with the following arrangement it works:

<txp:hide process="2">
    <txp:variable name="item_from_article" wraptag="h2" class="my-class" />
</txp:hide>
…
<txp:article form="article_single" listform="article_single" limit="1" />

The section in the txp:hide block is output as real text.

What am I doing wrong with the first variant?

Textpattern CMS

Textpattern CMS support forum

#49 2022-06-05 07:22:54

Re: Glossary architecture

#50 2022-06-05 08:50:05

Re: Glossary architecture

Bloke wrote #333528:

#51 2022-06-05 13:15:35

Re: Glossary architecture

#52 2022-06-05 14:56:33

Re: Glossary architecture

#53 2022-06-05 14:59:37

Re: Glossary architecture

#54 2022-06-05 16:04:31

Re: Glossary architecture

Bloke wrote #333531:

#55 2022-06-06 08:46:55

Re: Glossary architecture

Bloke wrote #333531:

#56 2022-06-06 10:44:55

Re: Glossary architecture

etc wrote #333535:

#57 2022-06-06 16:08:37

Re: Glossary architecture

etc wrote #333529:

etc wrote #333535:

#58 2022-06-06 17:34:42

Re: Glossary architecture

#59 2022-06-07 09:32:06

Re: Glossary architecture

jakob wrote #333539:

#60 2022-10-13 20:12:59

Re: Glossary architecture

etc wrote #333535:

etc wrote #333541:

Board footer