Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2019-10-17 07:18:31

etc
Developer
Registered: 2010-11-11
Posts: 5,133
Website GitHub

Auto trim list items

Suppose we want to output a comma-separated list like Category1, Category2, ... A natural approach would be

<txp:category_list categories="category1, category2, ..." break=", ">
    <txp:category title />
</txp:category_list>

but it returns

    Category1
,
    Category2
,
    ...

which is displayed as Category1 , Category2, ... (note the space before commas) by most browsers. To fix it you need to remove linebreaks

<txp:category_list categories="category1, category2, ..." break=", "><txp:category title /></txp:category_list>

or post-trim the output

<txp:category_list categories="category1, category2, ..." break=", " trim="/\s+(?=,)/">
    <txp:category title />
</txp:category_list>

but it’s ugly.

Wouldn’t auto trimming the surrounding space before joining items be natural when breaking by commas and other literal strings? I hate to alter users input, but in this case it seems justified. And you could disable it setting global trim="" attribute.

Offline

#2 2019-10-17 07:35:57

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,703
Website

Re: Auto trim list items

Is this perhaps a factor of using the title attribute? While I use txp:category_list less in comparison to section_list or article_custom I don’t remember that behaviour at all. Usually using break="," replaces the regular br break.

That said, I find the various escape and trim attributes generally useful.


TXP Builders – finely-crafted code, design and txp

Offline

#3 2019-10-17 07:43:25

etc
Developer
Registered: 2010-11-11
Posts: 5,133
Website GitHub

Re: Auto trim list items

jakob wrote #319742:

Usually using break="," replaces the regular br break.

Yes, but it does not remove literal linebreaks after the opening <txp:category_list> and before the closing </txp:category_list> tags. And that’s my proposal, not only for category_list but all txp-generated lists.

Offline

#4 2019-10-17 07:48:50

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,703
Website

Re: Auto trim list items

etc wrote #319743:

Yes, but it does not remove literal linebreaks after the opening <txp:category_list> and before the closing </txp:category_list> tags. And that’s my proposal.

Ah yes, I see what you mean. Yes, that would be very useful. In cases where I populate a variable like that I use escape="trim" but that doesn’t help for direct use as tag-in-tag-attributes. Splitting the code over several lines makes it more readable too. So … good idea 👍.


TXP Builders – finely-crafted code, design and txp

Offline

#5 2019-10-17 08:05:22

etc
Developer
Registered: 2010-11-11
Posts: 5,133
Website GitHub

Re: Auto trim list items

jakob wrote #319745:

In cases where I populate a variable like that I use escape="trim" but that doesn’t help …

Like all global attributes, it is (usually) applied to the final list, not to individual items.

Offline

#6 2019-10-17 10:19:29

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,419
Website GitHub

Re: Auto trim list items

etc wrote #319747:

Like all global attributes, it is (usually) applied to the final list, not to individual items.

So is there any mileage in introducing an escape="trimlist" or trimeach or some such attribute? Or does that open up a heap of implications for the introduction of other transforms at the list item level?

Wouldn’t auto trimming the surrounding space before joining items be natural when breaking by commas and other literal strings? I hate to alter users input, but in this case it seems justified. And you could disable it setting global trim="" attribute.

So this proposal is effectively that if you use break="something-that-isn't-a-tag" you pre-define the escape="/\s+(?=,)/" attribute? That way you can override it with escape="" or something if you really want line breaks preserved.

How does that affect things if you want to use escape for any other purpose? Wouldn’t that override this built-in value? Or are you thinking of some other internal mechanism to render this?

Example:

<txp:images break=", " escape="json">
   <txp:image_id />
</txp:images>

Also, how would you determine if the break is some literal compared to a tag? Whitelist a few known delimiters such as comma, comma+space, semicolon, etc? break="br" and break="div" and break="fish" surround elements with tags that include < and >, even if only two of them are valid HTML.


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

#7 2019-10-17 10:38:47

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,703
Website

Re: Auto trim list items

etc wrote #319740:

And you could disable it setting global trim="" attribute.

That’s important to, as you might deliberately want to do break=" ".


TXP Builders – finely-crafted code, design and txp

Offline

#8 2019-10-17 10:47:04

etc
Developer
Registered: 2010-11-11
Posts: 5,133
Website GitHub

Re: Auto trim list items

Bloke wrote #319751:

So is there any mileage in introducing an escape="trimlist" or trimeach or some such attribute? Or does that open up a heap of implications for the introduction of other transforms at the list item level?

I thought of introducing some “starred” pre-process versions of global attributes, so *escape="trim" would trim $thing before the tag is processed. Pre-processing global atts are useful anyway (cache etc) and planned. But that’s not equivalent to escaping each list item after processing and looks confusing.

So this proposal is effectively that if you use break="something-that-isn't-a-tag" you pre-define the escape="/\s+(?=,)/" attribute? That way you can override it with escape="" or something if you really want line breaks preserved.

How does that affect things if you want to use escape for any other purpose? Wouldn’t that override this built-in value? Or are you thinking of some other internal mechanism to render this?

Also, how would you determine if the break is some literal compared to a tag? Whitelist a few known delimiters such as comma, comma+space, semicolon, etc? break="br" and break="div" and break="fish" surround elements with tags that include < and >, even if only two of them are valid HTML.

I wouldn’t use escape, we have a global trim attribute. The plan is to trim list items automatically (unless trim="" is set) if break is not HTMLish. We check already the latter via preg_match('/^\w+$/', $break) in doWrap() function. This is not fully BC, whence this poll. Possibly, a more prudent idea would be using valueless trim:

<txp:images break=", " trim escape="json">
   <txp:image_id />
</txp:images>

Offline

#9 2019-10-17 10:48:36

etc
Developer
Registered: 2010-11-11
Posts: 5,133
Website GitHub

Re: Auto trim list items

jakob wrote #319752:

That’s important to, as you might deliberately want to do break=" ".

This wouldn’t require trim="", because break itself is not trimmed.

Offline

#10 2019-10-17 11:05:54

etc
Developer
Registered: 2010-11-11
Posts: 5,133
Website GitHub

Re: Auto trim list items

It’s a one-liner anyway, so let’s test.

Offline

#11 2019-10-17 13:22:51

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,219
GitHub

Re: Auto trim list items

Tangentially related: I have to say I’m really appreciating the numerous small changes to tags, internals and other nerdy stuff recently. Thank you Stef, Oleg and other contributors!

Offline

#12 2019-10-18 06:54:44

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,138
Website

Re: Auto trim list items

etc wrote #319756:

It’s a one-liner anyway, so let’s test.

Based on a brief look at the code, and an equally short round of testing, it is an opt-in feature, correct?

FWIW, I think it is the correct thing todo. If you really want that space before the separator, add it manually (and in most cases, a non-breaking space is probably more appropriate).

—-
Also +100 for gaekwad’s comment.


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

Board footer

Powered by FluxBB