Feature Proposal: content of SEARCH{...} format tokens ($text, etc.) to be able to be encoded

Motivation

You may need to encode $text content, not the entire format parameter content. For example, when you have format="| something | $text |", if encode="entity" is present, not only $text content, but the entire format content is subject to the encoding, which means it cannot be rendered as a table.

This is also the case with $formfield(...), $query(...), and $pattern(...).

Description and Documentation

Introduce encode:ENCODING parameter to aforementioned format tokens. For example:

  • $text(encode:entity)
  • $formfield(Summary, encode:safe)
  • $query(text, encode:quote)
  • $pattern(.*?(from here.*?to here).*, encode:url)
In addition to $formfield(...) in a SEARCH format, you can retrieve a TWiki form field value by %META{"formfield" ...}%, which should be able to be encoded for consistency.

Examples

Impact

Implementation

-- Contributors: Hideyo Imazu - 2013年01月31日

Discussion

Good point. Looking at FormattedSearch, the same can be said for $summary and $formfield().

Instead of a new parameter, how about adding new tokens to $text, $summary and $formfield()? For example, $text(encode:entity) would entity-encode the the text, and $formfield(Summary, encode:html) would html-encode the form field called Summary. This is consistent with existing tokens of $summary and $formfield().

-- Peter Thoeny - 2013年01月31日

Makes a lot of sense. I've updated the proposal accordingly and matched the topic name.

-- Hideyo Imazu - 2013年01月31日

It is logical to add the encode option also to $pattern(). It might be tricky to parse that reliably. Currently the end of the pattern is defined by a .*), e.g. as documented the pattern must end in .*. If we allow optional encode, we need to tweak the regex to reliably detect it and still allow arbitrary patterns. Untested:

$out =~ s/\$pattern\((.*?\s*\.\*)(, encode\:[a-z])?\)/getTextPattern( $text, 1,ドル 2ドル )/ges;

-- Peter Thoeny - 2013年01月31日

Feature accepted by JerusalemReleaseMeeting2013x02x01.

-- Peter Thoeny - 2013年02月01日

While implementing the enhancement, I realized that $summary doesn't need encoding because it's table safe. And $query(...) should have encoding option.

-- Hideyo Imazu - 2013年02月08日

Not sure, there might be a need to URL-encode summary or query text.

-- Peter Thoeny - 2013年02月08日

I have not problem providing encode:type option to $summary if needed. But as far as I see, it's cleaned in various way already. At least the value doesn't contain new line or the vertical bar character. So I cannot see a use case.

To put a text area field of a TWIki Form $query(Fieldname) can be used and to put it on a table, it needs to be encoded. In this particular case, $formfield(Fieldname) does the job, but I guess there are cases where $query(...) having no synonym in $formfield(...) yield new line and/or vertical bar containing results, which needs to be encoded in some cases.

-- Hideyo Imazu - 2013年02月09日

Edit | Attach | (削除) Watch (削除ここまで) | Print version | History : r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2013年02月18日 - HideyoImazu
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.

AltStyle によって変換されたページ (->オリジナル) /