Item13988: Dynamic search of values for a form fails

I have an app where I want to dynamically populate the pick list of a select field using a SEARCH like it is documented

Best is to take examples.

I will put the 3 elements in verbatim

First we need a form SubmissionRecordForm

---+ Submission Record Form

| *Name:*| *Type:* | *Size:* | *Values:* | *Tooltip message:* | *Attributes:* |
| Headline | text | 80 | | Title of change request | |
| Description | textarea | 80x8 |  | A short desctiption of the issue. More details can be added to the SR topic | |
| Originator | text | 40 |  | Person that raised the SR | |
| Assignee | select | 1 | %SEARCH{"\| option \|" topic="ProjectMembers" regex="on" nonoise="on" casesensitive="on" multiple="on" format="$pattern(.*?\|\s*([^\|]*?)\s*?\|[^\|]*?\|[^\|]*?\|.*)" separator=", "}% | Person the SR is assigned to | |

And we need a list of project members and it would be natural to have these in a table. ProjectMembers

---++ Project members

   * Set NOAUTOLINK = off

To add a member make sure that
   * The person is registered on the wiki. If not you can do it for the person on [[System.UserRegistration]]
   * The name is the wikiname
   * Put the new name in alphabetical order ABOVE the Former Employees line
   * Make the 2nd column exactly the string "option" with exactly 1 space before and after

To remove a member change the "option" to "former" in the 2nd column and move the item below the Former Employees item. Do not delete the row.

| *Name* | *filter* | *Department* |
| VioletteChayer | option | DE Schaumburg |
| DianeChayer | option | DE Penang |
| KennethLavrsen | option | SC Berlin |

And finally a record that has the form attached SubmissionRecord0001 which is just totally empty with the form added and the topic saved.

Now edit the SubmissionRecord0001 and note the pull down list for the Assignee

It contains every line from the ProjectMembers topic. Not just the table rows. All the lines. Each line becomes a value.

If I alter the search line in the form to

| Assignee | select | 1 | %SEARCH{" option " topic="ProjectMembers" regex="on" nonoise="on" casesensitive="on" multiple="on" format="$pattern(^. *([A-Za-z]+?) .*)" separator=", "}% | Person the SR is assigned to | |

then it works. It seems to be the vertical bars inside the regexes that breaks it all

-- Main.KennethLavrsen - 24 Feb 2016 - 16:42

Some updates

• Things work like they did in 1.1.9. We did not break anything in 2.1
• Thing SUCK in 1.1.9 and 2.1
• If we fix it that also SUCKS unless we THINK very carefully

here is the deal

• SEARCH for a regex in a normal topic inside a table or outside a table uses normal regex strings when you use a regex type search.
• Like in any regex if you want to search for a vertical bar - you must escape it with \|
• If you put a SEARCH to produce values in a form definition topic and you use \| in the regex - the search will work when you view the form topic. This is what you do when you develop your application and view the form topic
• When you edit a topic using the form you just created it FAILS if you have \| in the regex
• If you double escape all the vertical bars in the regex then it FAILS when you view the form topic. But the search actually WORKS in when you edit the topics using the form

It is a hopeless way it works seen from the poor app developer who is already fighting to get the regexes to work. First you have to make a regex that works. Then you have to break it again by adding extra \ to all vertical bars and by trial and error check that it works when you edit topics with the form.

It should not need the double \\|

But if we fix it we may break existing apps where people have found out by experiment that the \\| works.

How can we fix this in a compatible way

A safe way to use | in a regex that works both when you view the form topic and use the form is to make all literal vertical bars as a character class. Ie. [\|]

That works with a single escape both when you view it and use it.

An example of a search that is safe to use is

%SEARCH{"[\|] option [\|]" topic="ProjectMembers" regex="on" nonoise="on" casesensitive="on" multiple="on" format="$pattern(^[\|] *([^\|]+?) *[\|].*)" separator=", "}%

-- KennethLavrsen - 24 Feb 2016

I think the best goal would be to make the single escape work, and the fix should still allow the double escape to work also, when you edit a topic with a search. This way we maintain compatibility with previous behaviour while getting a proper spec. The downside would only be that you in this special case - a search in a form topic - you cannot search for a backslash which is what a double backslash really should mean

-- KennethLavrsen - 25 Feb 2016

Commenting is disabled while not logged in