Raw Literal Strings in Calculations

Idea created by mrwatson-gbs on Nov 16, 2015


    This idea is one improvement in string processing functions.


    In the current shipping product (FileMaker 14) it is only possible to embed raw text in a solution by placing it in a data field, or by using the Insert Text step (which requires a field on a layout) - both of which make a solution unnecessarily complicated. In all other cases strings in calculations must be duly (and tediously) quoted and escaped and line endings need correcting.


    Here is an example of the mess you get, when encoding text as  a FileMaker string (fished out of the internet):


    Screen Shot 2015-12-29 at 10.12.24.png


    Developers need a mechanism to insert strings into calculations, WITHOUT having to put them in quotation marks, escape them, and correct the line endings. A syntax is needed so that raw literal strings can just be pasted into calculations, something equivalent to CDATA Sections in XML or raw string literals in C++11. (See  the section on raw stings on then String literal - Wikipedia, the free encyclopedia page)


    There are however many different syntaxes (see discussion / comparison / pros+cons of raw string literal syntax at RFC: Syntax for raw string literals · Issue #9411 · rust-lang/rust · GitHub) and, should this feature be implemented, it is necessary to find a syntax that best reflects "the FileMaker Way" of doing things.


    Here is an example of a possible syntax (which I am not purveying here as THE syntax, but as A syntax):


    Set Web Viewer [ "wv" ; "data:text/html," & &&MYHTML




    Hello World




    & "?param" = $param]


    which is equivalent to


    Set Web Viewer [ "wv" ; "data:text/html," &

    "<html>¶" &

    "<head/>¶" &

    "<body>¶“ &

    "Hello World¶" &

    "</body>¶" &


    & "?param" = $param]


    In this example:


    • The raw text is indicated by a double ampersand followed by the delimiter (here MYHTML)
    • The raw text starts on the following line
    • and continues until the delimiter is encountered at there start of a line
    • Note the lack of quotation marks around the raw text.
    • The syntax of this example is particularly good for multiline raw text (requiring returns between delimiter & raw text) however it is a rather clumsy syntax for raw single-line expressions (e.g. windows-paths (or regular expressions)). The C++11 raw string syntax ( R"optionalDelim(raw text)optionalDelim" ) may be a better choice if single line raw string literals are to be supported (See http://stackoverflow.com/questions/19075999/what-is-the-rationale-for-parenthesis-in-c11s-raw-string-literals-r).


    (Note also that data urls are not actually allowed to have a parameter at the end - but for the sake of this example I have added a parameter to illustrate how a raw string literal would end.)



    • Raw literal strings will save a lot of programming time
    • Programming is more enjoyable / less tedious
    • The number of errors in code due to incorrect escaping and line endings will be reduced
    • Code will be simpler and more legible
    • Code will be easier to update + maintain
    • Performance: Raw literal strings do not need to be parsed, and so may offer a small performance improvement.
    • FileMaker will be regarded more as a modern programming language.


    Use Cases


    1. Generate web viewer content much more easily by being able to embed content directly into the web viewer calculation or scripts.
    2. Export data with XML + XSLT much more easily by being able to embed the XSLT directly into scripts.
    3. In general embed the contents of any text files (ini files, XML/XSL files, whatever) for direct use or for saving to external files
    4. Windows file paths, e.g.: when exporting data or referring to external files via a $Path variable on a windows system Set Variable[$Path ; <Raw literal string to save escaping all the backslashes> ]
    5. Double or even multiple-escaping situations, e.g.: with Evaluate or the list CF: When constructing a calculation string which itself is complicated (containing escaped characters and backslashes) for later evaluation the doubly escaped code can be agonizingly confusing.
    6. When constructing data-urls, as in the example above
    7. ... and pretty much everything / everywhere!



    Thanks for voting this idea up and please help find a syntax which best fits "the FileMaker Way" of doing things!