Glossary architecture

Destry · 2022-06-04 16:41:22

I don’t have the site online yet, and this has proven to be a complicated topic to write about here, so let’s forget all the above, for now, and let me walk through one tiny thing at a time, using images of the site and the code so far running things.

You may recall I was using this glossary as a model to build by, and I’m still doing that, though I now think I’m shooting for something a whee bit more complicated than the alphabet anchor links used in that other example. But I’ll come back to that later. One little step at a time here so I can underatnd the markup I currently have.

Here is a grab of my current glossary section default view:

(Images won’t display in the boards, so you just get links.)

image: Default Glossary view

And here’s the markup in that Page. The ‘hide’ comments may or may not be correct; it’s just how I think it works at this point, and I don’t even understand it completely:

<txp:output_form form="tmpl_opener" />

<article id="glossary-default">
  <txp:if_article_list>
    <header class="section-title">
      <h1>Glossary</h1>
    </header>

    <p>When the glossary fills to a prodigious volume, if ever, a search box will be added; until then, it's probably not needed.</p> 

    <h2 id="cats">Categories</h2>
    <div class="catbox">
        <p><a href="<txp:site_url />glossary/#cats">All</a></p>
        <txp:category_list 
             parent="letters" 
             exclude="letters,i,l,n,o,q,u,v,x,y,z"
             wraptag="ul" 
             break="li" 
             class="catslist" 
             sort="name asc">
          <a href="<txp:site_url />glossary/?c=<txp:category />#result"><txp:category title /></a>
        </txp:category_list>
    </div>

    <txp:if_category>
        <h3 id="result">Available entries for <a class="active"><txp:category title /></a>:</h3>
    </txp:if_category>
    <txp:if_category name='<txp:category />'>
        <txp:hide>
          Plus alphabetized list of articles filtered by the category;
          see article tag below, which handles it
        </txp:hide>
    </txp:if_category>
  </txp:if_article_list>

  <txp:hide>
    The following txp:article tag does one of two things, depending on context:
     - In default section view, it outputs the full glossary list as alphabetical sublists.
     - In individual article view, it shows a single full article via the 'default' form.
  </txp:hide>

  <txp:if_article_list>
     <txp:article sort="UPPER(Title)" 
		          breakform="glossary_blocks" 
		          breakby="glossary_sublists"  
                  listform="glossary_terms_alphabetical"
                  class="glossary_terms" />
  <txp:else />
     <txp:article form="glossary_article" />
  </txp:if_article_list>
</article>

<txp:output_form form="tmpl_closer" />

So, under the ‘Categories’ heading you see ‘All’ and a number of capital letters. The letters are currently categories. All 26 letters exist, but only these currently have live status example articles assigned to them, so I’ve excluded the categories that do not so far. The ‘All’ link is not really a category but just a default section link to help users put things in default (all glossary entries) view/mode after they’ve clicked other categories.

For example, here’s the view if the ‘P’ category link is clicked. Note these letters function as glossary filters, which is different than how that other glossary works, which simply jumps down to that letter’s block (via anchor links).

image: Filtered P view

Maybe you see what the first problem is… All category letter blocks in the default view after ‘K’ do not show up, but they are there, and you see them individually if you click their letter in the filtered view. Why do they not all show in the default view?

Hold that thought…

Let’s bring in the article tag, because I don’t really understand what’s going on there at all. I’ve never used an article tag like that before, and I’m just going with the suggestion that came from earlier in this thread (or somewhere):

<txp:article sort="UPPER(Title)" 
             breakform="glossary_blocks" 
             breakby="glossary_sublists"  
             listform="glossary_terms_alphabetical"
             class="glossary_terms" />

What does UPPER(Title) mean? What is it doing?

And here are the referenced Forms…

breakform="glossary_blocks":

<txp:hide> 
Works in relation to the 'glossary' page for full glossary output.
Note the 'yield' tag in the h3 header calls a 'breakby' item, which is defined in the glossary page as the 'glossary-sublists' Form, thus it is calling the ouput of that Form.
</txp:hide>

<section class="alphablocks">
    <h3><txp:yield item="breakby" /></h3>
    <ol class="termslist"><+></ol>
</section>

breakby="glossary_sublists":

<txp:hide> 
   Works in relation to 'glossary_blocks' Form. 
</txp:hide>

<txp:evaluate query='substring(<txp:title escape="quote" />, 1, 1)' escape="upper" />

What is that Form doing? I have no clue, other than what the comment says.

listform="glossary_terms_alphabetical":

<txp:hide>
           Used in relation 'txp:article' tage on 'glossary' page.
</txp:hide>

<txp:if_article_list>
      <li>
        <txp:permlink>
          <txp:title escape="tidy,textile" />
        </txp:permlink>
      </li>
</txp:if_article_list>

I’ll stop there. It’s not the last of my questions, but… baby steps.

Summary:

Why do I not get all letter blocks in the default view?
What does UPPER(Title) mean/do? (Just so I know.)
What does the evaluate tag in the glossary_sublists form do?

Last edited by Destry (2022-06-04 21:55:26)

Bloke · 2022-06-04 19:47:39

Destry wrote #333525:

Why do they not all show in the default view?

Guessing it’s because the default limit attribute is 10 for one of your tags, perhaps? Not sure. It’s not obvious what controls that page output from first glance.

What does UPPER(Title) mean?

It upper cases the title before sorting so you don’t get ‘L’ appearing before ‘a’.

Will check in more detail later and see if I (or someone else) can answer the others.

Destry · 2022-06-04 21:37:53

Bloke wrote #333526:

Guessing it’s because the default limit attribute is 10 for one of your tags, perhaps?

You are right. Staring me right in the face. The article tag lacked a higher limit.

For some reason I thought the default was unlimited until you limited it by a smaller number.

It upper cases the title before sorting so you don’t get ‘L’ appearing before ‘a’.

Ah. Okay. Thanks.

Last edited by Destry (2022-06-04 21:40:21)

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 support forum

#46 2022-06-04 16:41:22

Re: Glossary architecture

#47 2022-06-04 19:47:39

Re: Glossary architecture

Destry wrote #333525:

#48 2022-06-04 21:37:53

Re: Glossary architecture

Bloke wrote #333526:

#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