Making proposals

This section of the wiki is here for community proposals. Anyone may make a proposal. If you have a proposal for modifications to the coding style guide or best practices then please create a sub-page here. Once the page has been verified, proofed and accepted for inclusion, we will then move it into the main site.

If you have not already signed up to the mailing list then please see the Getting Involved section.

The current proposed items can be found in the sidebar or below within the child pages.


  • No labels


  1. If we're going to have a space for proposals, shouldn't there be a process for approving a proposal? Overly rigorous processes have killed other standards attempts in the cradle, so I don't want to over-think this. Should something be accepted when a minimum threshold of the core contributors agree to it? (And what should that be? One? A majority? A consensus?) Should there be a minimum commenting period (a day? a week?) before accepting a proposal?

    1. My vote is to be really fluid with this. I think you guys have the ability to move pages around like I do - right?.

      If the standard or best practice reads well, then feel free to move it in to the respective area.

      As long as it doesn't conflict with other things, I would say we give it something like 5 business days and if none of the core members vehemently objects then move it in.

      Like the Script Parameter custom functions. I've not spent the time to read what you've got but I imagine it's good!

  2. Anonymous

    One subject you have discussed is name-value pairs. In those discussions you have briefly mentioned "FSON" - a half-way FileMaker JSON-like format.

    I wonder if anybody has considered actually using the real JSON standard; and developing parsing methods to read and write standard JSON for Filemaker internal use (script parameters, variable assignment, etc.)

    It seems to me that besides general use consistent with current applications of name-value pairs, being able to create standard JSON may have value in web viewers. If you're already dealing in JSON then applying it to a web viewer would be something you could do immediately.

    - Bruce Robertson

    1. Many corners of the web have raise the possibility of using JSON for passing data around in FileMaker, but I've only heard of one or two people actually doing it.

      One force acting against JSON is that the competing Let notation ("FSON", a name we're trying to get away from) has the same advantage in FileMaker that JSON has in JavaScript: the data format is built with same building blocks as the language that's parsing it, making it much easier to parse. More importantly, this means that (FileMaker) developers don't have to be familiar with any non-FileMaker technology to use the technique. It's unsafe (if not unreasonable, or at least unsporting) to expect developers in one technology to be familiar with another.

      A problem with JSON and the conventions here is that the #* dictionary functions we define here is that no amount of clever re-coding of the #* functions will enable the same use patterns to create proper JSON. We can't re-write the #* functions to use JSON instead of Let notation without also re-writing all the code that uses the # ( name ; value ) function. On the other hand, YAML, which I like much better than JSON, could be handled within the existing #* function semantics.

  3. Anonymous

    Thanks for the comment. Your conclusion (or assertion) isn't immediately obvious to me as valid. I don't see why JSON couldn't be handled with a level of effort that is approximately identical to any other systematic approach. I also note that a YAML variant is "flow" style - that is, JSON.

    But I'll see if I can come up with some examples or see what happens when I try.


    1. I've also considered creating a set of JSON custom functions. I'd like the ability to have array's and preserve data type. Also, as you mentioned, it could give access to web services via a web viewer or the new Insert From URL script step.

      I can almost guarantee that the overhead of using a set of JSON custom functions will be substantially greater than those designed to work with Let format dictionaries. I've been working on a version of the # ( name ; value ) function that preserves data type and it's taking twice as long to encode the name/value pair than other versions of this function. I also think it will feel clumsy accessing data stored in JSON format, as I'm not sure how feasible it will be to pass in a "" and have it return a value that is multiple levels deep - which is what other languages that implement JSON allow.

      Nevertheless, if you do pursue writing these functions and want someone to bounce ideas off of, contact me (you should have access to my email via this site).

  4. JSON would be great for integration with web services, but it doesn't make a lot of sense for FileMaker unless FileMaker adopts JSON as a native data serialization format, which is something I continue to push for every time I can get the ear of any of the PMs and or Engineers at FileMaker Inc. They understand the issue, but its years a way, if it ever comes.

    Until then I am not convinced that JSON is the best data format to use internally with FileMaker  That said, we do need a way to do what JSON does, which is serialize and deserialize data.  Especially rich structured or nested data.  As some one who wrote two Data Serialization engines for serializing found sets of records and their related records for GoZync 1 and GoZync 3, I can say that it is very difficult to do something that is both easy to use and fast, for very large data sets.  But they may not be what we need.

    From Wikipedia

    JSON is built on two structures:

    • A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.
    • An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

    We have number 1 with the Let Notation.  What we don't have is the second one an ordered list of values.

    It seems like we should be able to add List support to the Let Notation. and its associated functions. ?????

    And if we had that, that would be useful in FileMaker, and it could be converted back and forth into JSON for use with the internets.

    This makes more sense to me



    1. I like where this is going. It looks like there are three tasks involved:

      1. implement array's in Let notation
      2. convert JSON to Let notation
      3. convert Let notation to JSON
        1. what would this be used for?
      1. convert Let notation to JSON

        1. what would this be used for?

        It would be used for taking a given FileMaker Let Data structure and converting it to JSON for sending to a web service.  


        1. I thought that if you were sending JSON to a web service, it would typically be with a POST request, which is not as easy to do in FileMaker without a plug-in. Do you know of any web services that accept JSON via a GET requests? Or, do you know of a trick to send POST requests from FileMaker?

          1. You can use web viewer to GET, POST, PUT, DELETE etc.


            1. Anonymous

              Hey, Todd!

              Thanks for your (and Daniel's and Jeremy's and Matt's) great contributions to this conversation. Your last post brought up something I don't understand, though.

              I would be very interested to know how you do a POST from a web viewer without a plugin. I have used a variety of plug-ins to do POSTs, but it would be great to find a way without a plugin, which means it MIGHT work in iOS. What tricks have you up your sleeve, Todd? 


              --Jonathan Fletcher

              1. Anonymous

                By "iOS" I meant Go. Sorry for the confusion.

                --Jonathan Fletcher

              2. not "Might". It does work on iOS.  Its not really much of a trick. Its just JavaScript set to fire onLoad

                1. Anonymous

                  Where might I look that up, Todd?

                  --Jonathan Fletcher

      2. It occurred to me over the weekend that task 1 in my list: "implement array's in Let notation" is actually pretty easy, so I just wrote two functions that I think cover the basic needs of this feature: #List and #ListGet. You can also use built-in functions to work with lists/array's in this format: ValueCount, LeftValues, RightValues.

        1. I had been handling array data within Let notation by using the de facto FileMaker equivalents. Either I would pass a return-delimited list as the value for a name-value pair, or I would set a series of entries with names using variable array notation:

          # ( "list" ; List ( "one" ; "two" ; "three" ) )
          & # ( "array[1]" ; "one" )
          & # ( "array[2]" ; "two" )
          & # ( "array[3]" ; "three" )

          ... then ...

          GetValue ( #Get ( $letData ; "list" ) ; 2 )
          #Get ( $letData ; "array[2]" )

          Do I understand correctly that your #List functions basically create a typed version of a return-delimited list? Would the resulting return delimited list be integrated with Let notation as a value in a name-value pair the same way JSON handles arrays? I.E., is this what you had in mind:

          # ( "list" ; #List ( ... ) & ... & #List ( ... ) )

          ... then ...

          #ListGet ( #Get ( $letData ; "list" ) ; 2 )
          1. Do I understand correctly that your #List functions basically create a typed version of a return-delimited list?

            Yes, typed and fully escaped, so the value can by anything, including another list or set of name/value pairs.

            I.E., is this what you had in mind:

            # ( "list" ; #List ( ... ) & ... & #List ( ... ) )

            ... then ...

            #ListGet ( #Get ( $letData ; "list" ) ; 2 )

            Yes, it is. And just to be clear, these are also possible:

            // any value is valid, and will be properly escaped
            #List ( # ( "first" ; "Dan" ) & # ( "last" ; "Smith" ) )
            & #List ( # ( "first" ; "Jeremy" ) & # ( "last" ; "Bante" ) )
            // preserved data type:
            #ListGet ( #List ( Date ( 1 ; 1 ; 2012 ) ) ; 1 ) + 7 = Date ( 1 ; 8 ; 2012 )

            I haven't checked, but I think that with the addition of these functions, all data structures that exist in JSON also exist in the "#" functions, which means it's now possible to convert data in this format to/from JSON.