Auto trim list items

etc · 2019-10-17 07:18:31

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.

jakob · 2019-10-17 07:35:57

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.

etc · 2019-10-17 07:43:25

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.

jakob · 2019-10-17 07:48:50

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 👍.

etc · 2019-10-17 08:05:22

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.

Bloke · 2019-10-17 10:19:29

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.

jakob · 2019-10-17 10:38:47

etc wrote #319740:

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

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

etc · 2019-10-17 10:47:04

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>

etc · 2019-10-17 10:48:36

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.

etc · 2019-10-17 11:05:54

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

gaekwad · 2019-10-17 13:22:51

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!

phiw13 · 2019-10-18 06:54:44

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.

Textpattern CMS

Textpattern CMS support forum

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