Glossary architecture

Destry · 2020-09-24 07:50:51

Bloke wrote #326053:

Oooh, there’s a typo or something’s been hacked out of that page by mistake. Will fix.

Thank you for your explanation and example fix! The added inline comment there also helps clarify some of the why. The why explanations often being what are missing in tag examples, but which make a big difference to understanding them. Anyway, I understand a bit better now. It seems dreadfully plain as day, which is embarrassing. Probably another one of those situations I keep relearning over and over.

etc wrote #326055:

Sorry, the progenitor was busy climbing boulders before it rains :-)

Never let me (or anyone) interfere with climbing boulders, or anything else that does not involve sitting in front of a computer.

I was only venting frustration at myself for not being able to self-help. I have a lot more research and content editing to do that will keep me busy as you climb several mountains first.

jakob wrote #326059:

. . . is it used often in everyday language?

Sorry about that. I try to kick the older/odd term around now and then.

Certainly not used in French everyday, or in English as a second language. ;) But I’ve grown up hearing it a fair amount. I had not realized it was chiefly North American, actually, but that’s a symptom of being part of the sample population, I guess.

In expansion of what the OED says (just looking at that), which is correct, copacetic is usually used as an alternative to strings that would involve with or to associations; e.g., ‘more in line with’, ‘jives with’, ‘more harmonious with’, ‘compatible with/to’, ‘okay with’, etc. So in the OED sense, you could compare it with ‘everything is okay with’, or ‘everything is copacetic with/to a native solution’, etc.

Btw, I had learned the word spondulicks here in the forum some time back (h/t Bloke). That was a good one.

Last edited by Destry (2020-09-24 08:05:33)

Destry · 2020-09-24 09:11:20

etc wrote #326055:

name="varname" attribute stores its output in <txp:variable name="varname" />.

Please bear with me as the moloko milk kicks in…

My mind wants to operate in page conciseness/cleanliness mode. If whatever defines a variable’s value in a containing tag can be put aside in a form (assuming that’s true) and called from there instead of bloating up the markup of a page template, how does that work? Like follows?

Form named form_with_variable:

<txp:if_variable name="varname"> . . . </txp:if_variable>

In page template:

. . .
<txp:hide>Here we want the form/variable value to be.</txp:hide>
<txp:output_form name="form_with_variable" />
. . .

And if that’s true, then <txp:etc_query name="varname"> . . . </txp:etc_query> is functionally the same as <txp:if_variable name="varname"> . . . </txp:if_variable>?

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

etc · 2020-09-24 09:33:54

Destry wrote #326065:

If whatever defines a variable’s value in a containing tag can be put aside in a form (assuming that’s true) and called from there instead of bloating up the markup of a page template, how does that work?

You can set (with <txp:variable name="varname"> . . . </txp:variable>) or check (with <txp:if_variable name="varname"> . . . </txp:if_variable>) and output (with <txp:variable name="varname" />) a variable everywhere (form, article body, etc) provided it is already defined somewhere else.

And if that’s true, then <txp:etc_query name="varname"> . . . </txp:etc_query> is functionally the same as <txp:if_variable name="varname"> . . . </txp:if_variable>?

No, it’s rather

<txp:variable name="varname"><txp:etc_query> . . . </txp:etc_query></txp:variable>

Destry · 2020-09-24 09:37:24

etc wrote #326058:

the stylesheet is already contained inside the second etc_query block.

Ok. That was how I initially read it. The more I stared at it, the more I doubted myself.

So just as it looks, then, an etc_query snippet.

Last edited by Destry (2020-09-24 09:55:12)

Destry · 2020-09-24 09:54:07

etc wrote #326066:

. . . and output (with <txp:variable name="varname" />) a variable everywhere (form, article body, etc) provided it is already defined somewhere else.

Whoa. Let me put this in different terms to see if I follow… 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?

Sorry, you must be pulling your hair out (if you have any left). I told you guys I have trouble grasping Txp variables. (Algebra, no problems.)

etc · 2020-09-24 09:55:00

Destry wrote #326067:

So just as it looks, then, and etc_query snippet.

Yep, you can simply copy/paste two code block of the example. Just make sure you have a custom field called synonyms; otherwise replace synonyms as appropriate in the first block.

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)

Textpattern CMS support forum

#31 2020-09-24 07:50:51

Re: Glossary architecture

Bloke wrote #326053:

etc wrote #326055:

jakob wrote #326059:

#32 2020-09-24 09:11:20

Re: Glossary architecture

etc wrote #326055:

#33 2020-09-24 09:33:54

Re: Glossary architecture

Destry wrote #326065:

#34 2020-09-24 09:37:24

Re: Glossary architecture

etc wrote #326058:

#35 2020-09-24 09:54:07

Re: Glossary architecture

etc wrote #326066:

#36 2020-09-24 09:55:00

Re: Glossary architecture

Destry wrote #326067:

#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

Board footer