Glossary architecture

etc · 2020-09-24 10:02:41

Destry wrote #326068:

You’re saying if I have a miscellaneous form named varname that contains some variable value, I can call that in a page using <txp:variable name="varname" />? Textpattern will just magically know to find that form by the variable name?

Or was that an indirect way of saying variable values can not be called by forms?

Nope, you call this form as usual, using <txp:output_form form="varname" /> or just <txp::varname />. What I meant is variables can be defined in one place (form or whatever) and used in another one.

Destry · 2020-09-24 10:09:30

etc wrote #326070:

Nope, you call this form as usual . . . What I meant is variables can be defined in one place (form or whatever) and used in another one.

Ah. Okay. No new voodoo I wasn’t aware of, then. That helps, thanks.

Destry · 2020-09-24 11:03:15

etc wrote #326069:

Just make sure you have a custom field called synonyms; otherwise replace synonyms as appropriate in the first block.

Yep. Thanks. I’m starting to see the convenience of using the Keywords field in this case, as I don’t imagine ever using tags (in the tag cloud sense) for this site, which is what I might have used Keywords for otherwise (or however smd_tags works). But I’ll ensure data="{{?keywords}}" if I do.

Destry · 2020-09-24 11:08:02

It occurs to me that the Tags Reference index would benefit from something like this if it was ever recreated in Txp. (Not raising/suggesting that old chestnut again.)

michaelkpate · 2020-09-24 12:15:03

jakob wrote #326059:

‘copacetic‘ is not a word I’ve heard before and I had to look it up.

As a Native NA English speaker, you don’t hear it used a lot. I think it was actually popularized back in the 1960s. And in a song a few years ago.

Local H – Bound For The Floor

And you just don’t get it
You keep it copacetic
And you learn to accept it
You know it’s so pathetic

Destry · 2020-09-24 14:43:57

Updated the glossary template with this piece:

<h2>Subcategories</h2>
<txp:category_list parent="groups" 
                   exclude="groups" 
                   wraptag="ul" 
                   break="li" 
                   class="catslist"  
                   sort="name desc">
        <a href="<txp:site_url />glossary/?c=<txp:category />"><txp:category title /></a>
</txp:category_list>

That made it consistent with the homepage groups list, thus easier to choose a different category if desired from the glossary section.

That does then beg for putting a <h2>Full List of [n] Entries</h2> above the full list part of the default view output, but it doesn’t appear I can easily do that with the default article tag behaviour as it is. It’s not a deal breaker, though, this is still better usability than it was, I think.

Also made a little front-end headway. It’s shaping up.

Last edited by Destry (2020-09-24 14:45:25)

jakob · 2020-09-24 14:46:16

michaelkpate wrote #326074:

As a Native NA English speaker, you don’t hear it used a lot. I think it was actually popularized back in the 1960s. And in a song a few years ago.

Local H – Bound For The Floor

Cool! Not heard that either. Now I know how to drop it casually into a conversation ;-)

BTW: A bit of that video reminded me immediately of the cover of The Endless Shimmering by the Belfast band “And So I Watch You From Afar” (ASIWYFA for short: similarly loud, more melodious but without lyrics).

Destry · 2022-02-25 09:31:49

Destry wrote #326047:

Resetting the stage for synonymous terms. The idea being to merge the current glossary architecture that works with etc_query to add synonymous terms to the glossary lists via a ‘synonyms’ custom field, or to achieve the same result in a native manner. Frankly, I don’t care which way it is . . .

I’ve had this on ice a while, but not forgotten. In total it’s been around six years and two different glossary projects since first thinking about the kind of glossary behaviour I’m aiming for, and Txp has perhaps evolved enough at this point that it can be done natively, so a native solution is preferable, but I’m still not sure it’s possible.

I’ve tried at great length in this thread to explain the scenario, so I don’t want to rehash too much (start reading here, if interested), but a current recap might be helpful…

I’m trying to mimic how this glossary handles non-linked terms in the glossary sub-lists (i.e. lists under glossary section A, B, C, etc.).

For example, under the A section on that glossary site you see these two associated entries:

Access Control List
ACL (see Access Control List )

In that example, let’s call ‘Access Control List’ a primary term in the glossary, and ‘ACL’ a synonymous term.

Primary terms reflect assigned Txp articles and the linked term itself is the article’s title, as expected.

Synonymous terms are not article assignments (because we don’t want a gazillion empty articles in the articles panel just for that purpose) but nevertheless appear in the glossary terms list along with their associated parenthetical links to the respective primary terms.

It has been conceived, in theory, by people having more technical aptitude than I that the synonymous terms can be added to the glossary lists as described by adding them as comma-separated items (if more than one synonymous term) in the Keywords meta field of the associated primary article, or in a custom field for the purpose. And then some tag/php voodoo happens and — Presto! — the output generates as the lists and links suggest.

At this point I have my base primary term lists working and a few article drafts as examples (not many); that is, sub-categorized by A, B, C, etc and alphabetized in the respective lists. What I do not know how to do yet is embed the synonymous terms from associated primary article fields (whether Keywords, a custom field, or whatever).

Again, Txp has probably evolved even in the last 18 months, let alone the last six years, and I’ve never been good at following along with cutting-edge tag functionality development, anyway.

For you tag wizards, is there a native solution to this synonymous-terms equation; and can you give me something to test?

I can put the site online behind a login (which I was planning to do soon anyway), but that might not be until next week. If it would help said wizard, I can give you publisher rights at that point to have a personal look at things.

Last edited by Destry (2022-02-25 16:49:39)

Destry · 2022-02-25 09:57:51

Addendum. I will reread this thread to see if the viper is staring me in the face, but I vaguely recall it was not.

/ Later that day /

So, recalling the history better now, for those just joining or had forgotton, etc came up with a brilliant piece of the puzzle using XSL transforms and one of his plugins, and that puzzle piece may or may not still work six years on. But the end goal evolved a bit later, which was to be able to break up the glossary list output into sub-lists by alphabetical letter groupings (A, B, C, D…), just like the example glossary site mentioned above does. In other words, all terms (primary and synonymous) alphabetized in general, but also sub-listed alphabetically by letter groups. This was eventually realized as important for when filtering the glossary by letter categories (again, A, B, C, etc).

etc’s original solution, if I still understand correctly, did not take into account the second sub-list grouping output, because I did not ask about that originally (I didn’t know I would need it). So there is still the matter of trying to get all the way home.

There is also the prevailing question, as alluded to in the previous couple of posts, as to whether or not this can be done natively now; in other words, in a manner different that what etc originally conceived in 2016 using XSL and a plugin. And that got us to the point of a full list of terms, as he demonstrated (I’ve not achieved it with the glossary myself, yet) without the groupings.

voilà, current.

Last edited by Destry (2022-06-04 15:25:52)

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)

Textpattern CMS

Textpattern CMS support forum

#37 2020-09-24 10:02:41

Re: Glossary architecture

Destry wrote #326068:

#38 2020-09-24 10:09:30

Re: Glossary architecture

etc wrote #326070:

#39 2020-09-24 11:03:15

Re: Glossary architecture

etc wrote #326069:

#40 2020-09-24 11:08:02

Re: Glossary architecture

#41 2020-09-24 12:15:03

Re: Glossary architecture

jakob wrote #326059:

#42 2020-09-24 14:43:57

Re: Glossary architecture

#43 2020-09-24 14:46:16

Re: Glossary architecture

michaelkpate wrote #326074:

#44 2022-02-25 09:31:49

Re: Glossary architecture

Destry wrote #326047:

#45 2022-02-25 09:57:51

Re: Glossary architecture

#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:

Board footer