Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Ideas for emulating two file download categories?
Bloke wrote #337788:
Or maybe we don’t pass the thing directly to SQL but preprocess it? Internally replace underscores with
\_
and just document it that if people want to use wildcards they need to use*
which we internally preprocess to a regular underscore before passing to SQL.Bit of a hack.
Done, under your responsibility :-)
Bloke wrote #337760:
Not ideal, but less work than splitting the filename on a delimiter and adding headers when the prefix changes.
These bits are actually easy:
<txp:if_different>
<txp:file_download_name breakby="-" limit="1" />
</txp:if_different>
Offline
Re: Ideas for emulating two file download categories?
Just so I understand correctly (I can’t easily test atm):
Two wild cards: %
and *
(as an alias for the SQL _
). Do those two cover the same, e.g all assets in the example above?
Question: is the -
delimiter required? Or is that just a convenience (it certainly does make for a readable category names in the example).
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Ideas for emulating two file download categories?
phiw13 wrote #337814:
Two wild cards:
%
and*
(as an alias for the SQL_
). Do those two cover the same, e.g all assets in the example above?
Yes, %
is for any number of characters, and *
matches one character, à la sql _
. The underscore _
itself acts as a literal character, since it can be part of category names, unlike %
and *
.
Question: is the
-
delimiter required? Or is that just a convenience (it certainly does make for a readable category names in the example).
Not required at all, but is one of rare characters allowed in category names that is readable as delimiter when you need to split a name.
Offline
Re: Ideas for emulating two file download categories?
etc wrote #337816:
Yes,
%
is for any number of characters, and*
matches one character, à la sql_
. The underscore_
itself acts as a literal character, since it can be part of category names, unlike%
and*
.
Thanks! I understand now. The is certainly a useful feature. And yes the -
as part of the category name makes for readable and thus easy to use names.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Ideas for emulating two file download categories?
We already use wildcards in cf queries, so there is nothing really disruptive here.
Offline
Re: Ideas for emulating two file download categories?
Have finally been able to test this and while I think the idea is very neat, it leads to a proliferation of file categories in my case: I have one general category and (currently) 20 local office location categories, resulting in 21 × 4 = 84 categories for four file types (more if I nest the types under each location)… making for very long select menus.
If I have a thinking mistake here, please let me know.
——
So I investigated my original idea of using jcr_file_custom, if_different and sort. This works, but I’m struggling again with the correct syntax for breakby
and breakform
. This is what I have so far:
<txp:variable name="internal_file_types">logo, template, form, report</txp:variable>
<txp:file_download_list category='_all, <txp:article_url_title />'
wraptag="" break="" form="internal_downloaditem"
sort="FIELD(jcr_file_custom_2,<txp:variable name="internal_file_types" breakby="," escape="trim, quote" break="," />), category asc" />
where jcr_file_custom_2
is the column name for the file_download_type
file custom field. The FIELD(…)
bit is just to ensure the file type headings appear in the desired order as set in the variable, and I have renamed the general category _all
to make sure it always sorts before the various office locations.
The internal_downloaditem
form is as follows (slightly simplified here for better readability):
<txp:if_different>
</ul>
<txp:jcr_file_custom name="file_download_type" wraptag="h4" />
<ul class="internal-downloads">
</txp:if_different>
<li>
<a href="<txp:file_download_link />" class="item-url">
<p>
<txp:file_download_name title wraptag="strong" />
<txp:file_download_size wraptag="span" />
</p>
<txp:file_download_description wraptag="p" class="item-desc" />
</a>
</li>
<txp:if_last_file></ul></txp:if_last_file>
It works okay, but I have a stray </ul>
at the very beginning of the code. If I put <txp:if_first_file not></ul></txp:if_first_file>
in the first line of the if_different
conditional, it prevents the first </ul>
but of course results in two first file type headings because the if_different output differs due to the if_first_file.
I can’t help thinking it would be neater with breakby
, breakform
and <+>
, but I can’t work out the correct breakby
attribute. Using breakby="<txp:jcr_file_custom name='file_download_type' />"
causes txp to complain about using file-type tags out of context. I’ve tried regex expressions for the <h4>…</h4>
tag but to no avail. Any suggestions?
TXP Builders – finely-crafted code, design and txp
Offline
Re: Ideas for emulating two file download categories?
jakob wrote #338016:
If I put
<txp:if_first_file not></ul></txp:if_first_file>
in the first line of theif_different
conditional, it prevents the first</ul>
but of course results in two first file type headings because the if_different output differs due to the if_first_file.
You can try (untested)
<txp:if_different test='<txp:jcr_file_custom name="file_download_type" />'>
<txp:if_first_file not></ul></txp:if_first_file>
<txp:jcr_file_custom name="file_download_type" wraptag="h4" />
<ul class="internal-downloads">
</txp:if_different>
Using
breakby="<txp:jcr_file_custom name='file_download_type' />"
causes txp to complain about using file-type tags out of context.
That’s strange, will check.
Offline
Re: Ideas for emulating two file download categories?
Cool! It works!
Using test
as an attribute of txp:if_different
to point to the bit of code that we’re interested in watching for changes is something I didn’t know about or rather, something I have overlooked, as I can see from a site search that you have provided a few examples of it going back to 2018.
Getting rid of the leading closing tag was always a problem in the past and that neatly deals with it.
Thanks for pointing it out again.
TXP Builders – finely-crafted code, design and txp
Offline