Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Glossary architecture
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 because both are going to be a learning experience for me that I won’t be able to muster alone. More important to me, I think, is the approach that requires the fewest number of form templates and the fewest lines of markup overall. That makes a big difference when coming back to it years later and trying to remember what’s going on under the hood.
So for the sake of stepping off the bridge somewhere, I’ll recap what the current glossary architecture is and does (conditions satisfied), and then give a closer reflection on Oleg’s XSL approach. Later, if someone wants to propose a native solution, that’s fine, but be prepared to demonstrate the markup examples so I have a lead to start with.
Glossary behaviour conditions
Txp sections and pages have a 1:1 relationship. Just so you know.
Condition A (Default section):
- Visitor arrives to homepage, sees list of glossary categories. ✔︎
- When link in list is clicked, taken to Glossary section and shown list of related articles. ✔︎
- List of articles is sectioned into alphabetical sections by letter. ✔︎
- Only letter sections containing actual articles/terms appear. ✔︎
- When a given term link is clicked; full article is displayed. ✔︎
Condition B (Glossary section):
- Visitor arrives to Glossary via main nav link for glossary; sees full list of glossary terms (article titles). ✔︎
- Full list of terms is sectioned into alphabetical sections by letter. ✔︎
- Only letter sections containing actual articles/terms appear. ✔︎
- When a given term link is clicked; full article is displayed. ✔︎
Unlike with the original model for this idea, I do not at this time need a sub-navigation system for the lettered headings of the full glossary, so that can be ignored in architecture considerations. The glossary is for people new to traditional tools and woodworking, thus they probably don’t know what names to jump to anyway, and in any case, the homepage provides a categorical facilitation, at least. The aim for now is to encourage scrolling/perusing all the terms (there will not be thousands).
Latest pieces currently running the Glossary
Following are the current working pieces of the glossary. I’m happy with this. The only thing missing so far is the synonymous terms behaviour.
Default (home) template:
<txp:category_list parent="groups"
exclude="groups"
wraptag="ol"
break="li"
class="catslist"
sort="name desc">
<a href="<txp:site_url />glossary/?c=<txp:category />"><txp:category title /></a>
</txp:category_list>Glossary template:
<txp:if_article_list>
<h1 class="titre">Glossary</h1>
<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>
<txp:if_category>
<h2>Entries under <txp:category title /></h2>
<txp:hide>plus alphabetized list of articles filtered by the category</txp:hide>
</txp:if_category>
</txp:if_article_list>
<txp:hide>
in default section view, txp:article outputs the full glossary list.
in individual article view, txp:article shows a single full article.
</txp:hide>
<txp:article sort="UPPER(Title)"
breakby="glossary_sublists"
breakform="glossary_sections"
listform="terms_alphabetical"
form="default"
class="termslist" />In that last article tag, the referenced forms are…
listform="terms_alphabeticalis just a wrapping permlink tag on a title tag insidelis.form="default"is my full article view markup
And then…
glossary_sections form:
<section>
<h3><txp:yield item="breakby" /></h3>
<ol class="termslist"><+></ol>
</section>glossary_sublists form:
<txp:evaluate query='substring(<txp:title escape="quote" />, 1, 1)' escape="upper" />Synonymous terms: XSL approach
I have not attempted anything here yet with Oleg’s synonymous terms approach. I don’t even have etc_query installed yet. But just to think through it…
Step 1 of 2
Create a structured list of all terms (“main” and “synonyms”), retrieved directly from the database:
<txp:etc_query name="terms" markup="db" data="Section='glossary'" populate="article" wraptag="ol">
<li data-title="{!title||strtolower}">
<txp:permlink><txp:title /></txp:permlink>
</li>
<txp:etc_query data="{{?synonyms}}" markup="list">
<li data-title="{{$strtolower}}">
{{?}} (see <txp:permlink><txp:title /></txp:permlink>)
</li>
</txp:etc_query>
</txp:etc_query>And store it in <txp:variable name="terms" />.
Right away I’m wondering how to ‘store’ that snippet into a txp variable, because variables always confuse me.
But after that curiosity, I can see that the query is pulling the two kinds of terms (main and synonyms) and already making them into a functioning — but non-alphabetized — terms list. I don’t know what the markup="" and populate="" tag attributes mean/do, but my ignorance probably isn’t a show stopper to them working.
Since I don’t know how to treat this variable at the moment, I’ll move on, but it seems I will need to merge this concept into my my existing glossary page markup somewhere, and since the synonymous terms does not account for the lettered section headings, as already established in my markup, then it should be somewhere below that so it doesn’t interfere with lettered sections, or so the reasoning goes.
Step 2 of 2
Reorder the li items of this stored list by their data-title attribute:
<txp:etc_query data='<txp:variable name="terms" />'>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html" encoding="utf-8" omit-xml-declaration="yes" />
<xsl:template match="ul">
<ul>
<xsl:for-each select="li">
<xsl:sort select="@data-title" order="ascending" />
<xsl:copy-of select="." />
</xsl:for-each>
</ul>
</xsl:template>
</xsl:stylesheet>
</txp:etc_query>Again, I don’t know what to do with this because I’m faced with something I’ve never used before, an XSL stylesheet. Does that style need to go in a separate styles file? In the head of the page template? Directly into the main markup? Or do I need to create a new page template in XML doctype?
Also, how must it be changed to merge with the existing structure?
This might be where Oleg can shed light, but I am not in a rush.
If those much wiser than me, including the progenitor of the above solution, suggest a native approach to the problem; perhaps one that is more copacetic to the existing markup… I’m all ears. The more concise the markup and less need for forms, the better I like it.
Last edited by Destry (2020-09-24 14:28:17)
Offline
Re: Glossary architecture
Destry wrote #326047:
Right away I’m wondering how to ‘store’ that snippet into a txp variable, because variables always confuse me.
For example, I’m looking at the actual doc for the variable tag, and I’m guessing the first example is the relevant one simply because I see the word ‘store’ being used there, as is used here. And I’m looking at it… and I’m like, what in that big search snippet is being stored?
- The whole snippet?
- Just the part between
<txp:else />and</txp:if_category>where the variable tag is actually hiding? - Is that why it’s positioned at that location when the lead paragraph to that snippet says ‘Somewhere at the very beginning of a template’?
- (I don’t have a desktop calculator or know how to use memory keys.)
And there’s something twisty about that next line of instruction: ‘Later down the Page template or in a separate Form template you can read the attribute values previously set conditionals come in handy at times’. Eh? Previous set conditionals? So does that mean the whole if_search snippet was stored? And if so, why is the variable tag tucked where it is?
I’m not trying to be funny or smart here. I’m honestly trying to show my exact stumbling as I look at that example in user docs and try to make heads or tails of it. I can’t. I’m sure it makes perfect sense to the developer-minded, but… And many examples in tag docs are equally sparse in detail and clarification. Thus, in this case, I can’t use docs to help me with a real situation where it could, expectedly, be useful at helping me self-accomplish something (at least partly).
I sincerely don’t like being overly reliant on busy people that find this stuff elementary, and especially after straggling in and out here for nearly 2 decades (yipes). I really don’t. Part of it is I don’t work in web anymore, and not for a long time, and won’t again, and my own humble needs are low bar, usually, so not a lot of impetus on my part to raise the bar. Other life duties call, if you see what I mean. And I don’t envy the people who have to have the energy to maintain fix user docs for people like me. Believe me, I know what energy it takes to try and be clear in docs. But, unfortunately, I’m often reliant when it comes to Textpattern tag-fu, which is really where the main game is, isn’t it?
Just wanted to get that bit of frustration off my chest and let you know — and y’all know who you are — that I am extremely grateful for your helps now as ever I was.
But coming back to that example, and how it may or not apply to the synonyms objective this thread has most recently taken. Let’s say instead of an if_search snippet example, it’s actually giving the snippet example in Step 1 of 2 in the previous post. Where do I stick that snippet (page template? form? where the sun don’t shine?) and where does the variable tag go in relation? Little big things.
Offline
Re: Glossary architecture
Oooh, there’s a typo or something’s been hacked out of that page by mistake. Will fix.
In the meantime, the only bit that’s “stored” is the value of the <txp:variable> tag itself. In this case, the value 1 assigned to the variable called “homepage”. Once that’s set, you can then use:
<txp:if_variable name="homepage" value="1">
do something here because it's set
<txp:else />
do this if it's not set
</txp:if_variable>When you use <txp:variable> you can either set it to the given value or you can use it as a container and set it to the entire contents of the container. So:
<txp:variable name="destry" value="hello there" />and:
<txp:variable name="destry">hello there</txp:variable>Are functionally identical.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Glossary architecture
Destry wrote #326047:
Create a structured list of all terms (“main” and “synonyms”), retrieved directly from the database:
<txp:etc_query name="terms" markup="db" data="Section='glossary'" populate="article" wraptag="ol">...And store it in
<txp:variable name="terms" />.Right away I’m wondering how to ‘store’ that snippet into a txp variable, because variables always confuse me.
Sorry, the progenitor was busy climbing boulders before it rains :-) It’s just an etc_query feature: name="varname" attribute stores its output in <txp:variable name="varname" />.
TBC
Offline
Re: Glossary architecture
Destry wrote #326047:
Synonymous terms: XSL approach
I can see that the query is pulling the two kinds of terms (main and synonyms) and already making them into a functioning — but non-alphabetized — terms list. I don’t know what the
markup=""andpopulate=""tag attributes mean/do, but my ignorance probably isn’t a show stopper to them working.
These are etc_query attributes meaning ‘extract data from db’ (markup="db") and populate article fields (populate="article"). etc_query can extract data from many types of sources (db, json, html, etc) so it needs to know what it deals with.
Since I don’t know how to treat this variable at the moment, I’ll move on, but it seems I will need to merge this concept into my my existing glossary page markup somewhere
You can output it with <txp:variable name="terms" /> tags where you want (after <txp:etc_query name="terms" ... /> tag).
Step 2 of 2
Reorder the li items of this stored list by their
data-titleattribute:
<txp:etc_query data='<txp:variable name="terms" />'>...Again, I don’t know what to do with this because I’m faced with something I’ve never used before, an XSL stylesheet. Does that style need to go in a separate styles file? In the head of the page template? Directly into the main markup? Or do I need to create a new page template in XML doctype?
You don’t need to do anything (except learning bases of XSLT to understand what happens), the stylesheet is already contained inside the second etc_query block. The latter will transform the unordered <ul /> list stored in <txp:variable name="terms" /> according to this stylesheet, namely reorder it by title.
Also, how must it be changed to merge with the existing structure?
This is a tougher one, if you mean dividing the list alphabetically. Leave me some time to explore etc_query meanders.
If those much wiser than me, including the progenitor of the above solution, suggest a native approach to the problem; perhaps one that is more copacetic to the existing markup… I’m all ears. The more concise the markup and less need for forms, the better I like it.
Hmm, I can’t find a better native approach (unless we consider <txp:php />), would love to see one.
Offline
Re: Glossary architecture
etc wrote #326058:
This is a tougher one, if you mean dividing the list alphabetically. Leave me some time to explore
etc_querymeanders.
That sounds intriguing ;-)
Destry wrote #326047:
… perhaps one that is more copacetic to the existing markup… I’m all ears.
‘copacetic‘ is not a word I’ve heard before and I had to look it up. The dictionary says “North American informal” (which might explain it) but is it used often in everyday language? Anyhow, nice to learn something new :-)
TXP Builders – finely-crafted code, design and txp
Offline
Re: Glossary architecture
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)
Offline
Re: Glossary architecture
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)
Offline
Re: Glossary architecture
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>Offline
Re: Glossary architecture
etc wrote #326058:
the stylesheet is already contained inside the second
etc_queryblock.
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)
Offline
Re: Glossary architecture
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.)
Offline
Offline