FileMaker has developed a wonderful system of handling text that for the majority of users just make all the intricacies of processing and encoding text and line endings just go away: In FileMaker text is just text and line endings are just “¶”. This wonder stops sadly at the ‘doors' of FileMaker; the rest of the world must deal with character encodings and CR&/LF line endings.
- See The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) from Joel Spolsky
- and The Great Newline Schism from Jeff Atwood of Coding Horror
The Export Field Contents command exports text fields as UTF-16 text, at least on the desktop. On FMGO it exports in UTF8 - with OS-line endings.
The inability to choose the required encoding and line endings regularly means that this command is completely useless, and developers are forced to turn to plugin-solutions (or other complicated techniques with XSLT-export).
Extend the Export Field Contents command to
- make it possible to specify the encoding: Default | UTF-8 | UTF-16 | etc. (Where Default = backward compatibility mode = UTF-16 with FMP and UTF-8 with fmGO.)
- make it possible to specify the line-endings: Current System | Windows/DOS (CRLF) | Mac/Unix (LF) | Mac classic (CR)
- and (thanks to beverly’s suggestion) make it possible to enable/disable the BOM
I would also like to propose that such option fields also be specifiable by calculation, so that it is not necessary to build huge else-If structures to implement every combination of encoding + line endings, this is of course secondary to the main idea.
- Helps Improve FileMakers Integration Technologies
- FileMaker natively supports ALL (!) text based export-interfaces
- Leverages an existing command to become usable in 100% of export-situations instead of only around 4%
- Extremely simplified and maintainable code:
- no need for plugins
- no need for complicated custom functions to wrap the plugin functions
- no need for complicated path conversions
- no need for complicated plugin installation processes
- no need to process plugin-specific error codes
- Simplified support processes:
- no need to look up plugin specific errors
- no need to search the web for
- no need to download vendor specific OSErrrs database
- no need to engage in vendor specific support dialog, when something stops working and the plugin needs improving
- It’s more FileMakery:
- It’s easier to use
- It’s quick to learn: No need to learn all that troi file + path + CF + error stuff
- there are no hidden Gotchas
- Other benefits of native functions:
- it is centrally documented
- It is centrally maintained - Changes to the function are communicated in known ways
- it uses FileMaker standards (encoding names and line ending ‘names’ in the dialog)
- Less errors
- due to path problems
- due to lacking support in the plugin for
- due to falsely named encodings
- Greater productivity
- ALL text interfaces
- Exporting of ‘hand-written’ XML
- Exporting of ‘hand-written’ JSON
- etc., etc., etc., etc., etc.!
I have added this entry to the idea Improve string processing functions - since exporting a string is an extremely important aspect of processing strings.