Tags:
create new tag
view all tags

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
 
  • Learn about TWiki  
  • Download TWiki
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.