FileMakerStandards.org # functions as module

287 views
Skip to first unread message

jeremy...@gmail.com

unread,
Jul 1, 2013, 8:10:36 AM7/1/13
to modular-...@googlegroups.com
This thread is continuing a conversation Todd started on FileMakerStandards.org about moving the # functions into a formal module. I'm open to the idea — it certainly wouldn't take much additional work to package up as a module — but I think it's worth verifying that it's a good idea. Shortly before Todd launched ModuleFileMaker.org, I distinctly remember him advocating Let notation as a data format instead of the # functions. I was even inspired to write up some best practices for Let notation. I understand that the context of that was a little different, but I wonder if posting the # functions as a mFM module would make folks more willing to write modules with a dependency on those functions — something Todd advocated against for good reason. We can probably trust module developers not to get the wrong idea, but I think it's something that should be said (written?) out loud, at least.

When Dan and I worked on the recent overhaul to the # functions, we agreed to follow strict TDD methods in their development, which has made the functions much more robust than they might have been otherwise. I hope we can keep it that way. Passing multiple parameters to scripts is such a fundamental tool for FileMaker developers that it's worth the extra effort to be so rigorously tested. (The custom functions that support that testing might be worth a module of their own, but perhaps a test harness to go with them is in order first.)

While the #Error functions don't have much to stand on without the # functions, the # functions are fine without the #Error functions. I've personally found the #Error structures discussed on FileMakerStandards.org to be awfully "heavy" for my own comfort, but I suppose I'll get used to them if everyone else is using them. I might like to see some different names from what Todd listed, though:

#IsError — fine as-is.
#LastError — instead of #GetLastError
#Error or #NewError — instead of #CreateError

I personally find that when custom functions are named for the result they return (nouns) rather than what they do (verbs), the resulting calculations are more readable, given that FileMaker's calculation engine is so heavily result-centric (functional, rather than imperative). If anyone can come up with sensible names that all start with "#Error*" so that the functions cluster together in an alphabetically sorted list, that much the better; but all of them starting with # may be a good-enough start.

Todd Geist

unread,
Jul 1, 2013, 11:19:25 AM7/1/13
to modular-...@googlegroups.com


On Monday, July 1, 2013 5:10:36 AM UTC-7, jeremy...@gmail.com wrote:
 Shortly before Todd launched ModuleFileMaker.org, I distinctly remember him advocating Let notation as a data format instead of the # functions. I was even inspired to write up some best practices for Let notation. I understand that the context of that was a little different, but I wonder if posting the # functions as a mFM module would make folks more willing to write modules with a dependency on those functions

One of the things I love about the # functions is that they are pretty just sugar on the Let Notation.  I believe they are compatible.  If they are not it would be good to know where they aren't.  But if they are, then a dev can write a module that doesn't use #Assign, but consumers of that module can use #() if they want.  This is a big win to me.

When I launched ModularFileMaker I tried to do so with the smallest spec I could.  I did think that it would be useful to have a core mFM module, but I wasn't sure what would go in there.  So in the interest of starting lean I avoided it.  But I also tried to make it clear that writing modules that have dependencies is perfectly fine as long as you spelled them out.  So the idea that people would write modules that use the # family is still fine.

I could be convinced that we now know enough to put a core mFM module out there.  If so then # should be part of it.  That discussion should be a separate thread.

jeremy...@gmail.com

unread,
Jul 1, 2013, 12:26:57 PM7/1/13
to modular-...@googlegroups.com
On Monday, July 1, 2013 11:19:25 AM UTC-4, Todd Geist wrote:


One of the things I love about the # functions is that they are pretty just sugar on the Let Notation.

As implemented, yes. As originally intended, no. But since when have original intentions carried any weight? The original theory was that the functions could work with any format that was compatible with how they're designed to be used together, but I have a hard time imagining anyone deciding that it's worth it to implement the functions using anything else. If anything, narrowing the allowable scope of # functions to Let notation would make me more comfortable with the notion of wrapping them up as a module, since they would indeed then just be sugar for the interchange format of choice.

Todd Geist

unread,
Jul 1, 2013, 1:31:27 PM7/1/13
to modular-...@googlegroups.com
On Monday, July 1, 2013 9:26:57 AM UTC-7, jeremy...@gmail.com wrote:
 If anything, narrowing the allowable scope of # functions to Let notation would make me more comfortable with the notion of wrapping them up as a module, since they would indeed then just be sugar for the interchange format of choice.

So lets make that happen :-)

As to the Error functions being part of the # family or not. I get it. They aren't a perfect match. But it is awfully convenient to have them there in the same name space....

If there is a huge objection to adding them to that # family, could we define some kind of extension name space for them?  Perhaps "#_" or "##" or maybe "#x"
  • #xIsError
  • #xLastError
  • #xNewError
I like the idea of being able to "extend" something, but I don't know...

Daniel Smith

unread,
Jul 3, 2013, 1:54:49 AM7/3/13
to modular-...@googlegroups.com
On Monday, July 1, 2013 9:26:57 AM UTC-7, jeremy...@gmail.com wrote:
...but I have a hard time imagining anyone deciding that it's worth it to implement the functions using anything else.

Before I worked on the JSON module, I would have said the same, but I found two issues with the current format used:
  1. The name in the name/value pair is not escaped, which limits the characters that can be used.
  2. It's difficult to differentiate a name/value pair from an ordered list (as implemented with my #List custom function)
Issue #1 could be a dealbreaker for some when using my JSON module because it means you cannot use the custom functions to create JSON with a dash or colon, which were used in example JSON data found here: http://json.org/example.html.

I think workarounds could be created for both of these issues, but it started to make me wonder if this is really the ideal format, or if there is a viable alternative. I don't have any viable alternative at the moment, so I will continue to use this format and see if I can make viable workarounds for the above issues instead.

Daniel Smith

unread,
Jul 3, 2013, 2:56:40 AM7/3/13
to modular-...@googlegroups.com
Todd, can you elaborate on the role of this core module you mentioned?

I don't understand why a core module is needed rather than a separate module for each distinct feature.

Daniel Smith

unread,
Jul 3, 2013, 3:26:23 AM7/3/13
to modular-...@googlegroups.com
Todd,

Are the error functions you mentioned over here internally setting a reserved variable? Can you elaborate on how these functions are used, or post a link to the full functions so I can infer how they are used?

I like your idea of adding the "#" prefix to these functions.

jeremy...@gmail.com

unread,
Jul 3, 2013, 12:05:18 PM7/3/13
to modular-...@googlegroups.com
On Wednesday, July 3, 2013 1:54:49 AM UTC-4, Daniel Smith wrote:
Before I worked on the JSON module, I would have said the same, but I found two issues with the current format used:
  1. The name in the name/value pair is not escaped, which limits the characters that can be used.
I have no problem with that. Tools are designed to make particular tasks easier. (And if a tool is designed so that the implementation is easy, too, that much the better.) Let Notation and the # functions as currently written are designed to make setting FileMaker $variables easy. Tying the naming restriction to FileMaker's calculation syntax is just the natural thing to do, with that in mind. I'm happy to take inspiration from other formats like JSON and YAML (especially YAML), but I don't accept feature parity as a higher priority than convenience for implementation and FileMaker-centric use. If a developer needs to generate JSON keys with colons and hyphens, perhaps Let Notation is not the place to start.

Todd Geist

unread,
Jul 3, 2013, 5:16:54 PM7/3/13
to modular-...@googlegroups.com


On Tuesday, July 2, 2013 11:56:40 PM UTC-7, Daniel Smith wrote:
Todd, can you elaborate on the role of this core module you mentioned?

I don't understand why a core module is needed rather than a separate module for each distinct feature.

Just realized that my reply only went to Dan...  ( fixed that ) 

To be clear, I'm not 100% convinced that having a core module is a good idea. However, it's clear from my own experience working on several projects at the same time that there would be some benefit to having functionality like what's provided by the hash family of custom functions rolled into a module.  I think it should include a small subset of essential functions. Things like errors, rich data, script trigger disabling etc.  So I think step 1 should be to try to get this module together.  Then we can see if it is truly useful. If it is, it will become the defacto I standard.

Todd

Todd Geist

unread,
Jul 5, 2013, 5:20:30 PM7/5/13
to modular-...@googlegroups.com
Here is the full set of # functions including the error Extensions. 


I think most of this is pretty straightforward and what has been kicked around for a while. My biggest deviation from what Dan proposed a while back is to make the ErrorDataApp function into just #NewError(theErrorCode, theErrorType, theErrorText).  Its main purpose is to enforce the required structure. It does not include logic matching errorTypes and errorCodes to errorText. I think that should be left to the Module or Solution. Modules should be able to declare their own custom errors if they choose.  They can use a Module Level CF or script to wrap #NewError if they want too.

I had also been using another optional "note" field which I was using to uniquely ID that instance of the Error in the solution ( think Link numbers in php ) but I think that can be left out.

Here are the reserved vars that these would use:
  • $errorCode
  • $errorType
  • $errorText
Thoughts ?

Todd


 

Todd Geist

unread,
Jul 5, 2013, 5:27:30 PM7/5/13
to modular-...@googlegroups.com
I actually could live with out #AssignGlobal, I tihnk.

Todd

Todd Geist wrote:
--
You received this message because you are subscribed to the Google Groups "Modular FileMaker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modular-filema...@googlegroups.com.
To post to this group, send email to modular-...@googlegroups.com.
Visit this group at http://groups.google.com/group/modular-filemaker.
To view this discussion on the web visit https://groups.google.com/d/msgid/modular-filemaker/93df5098-57ec-4eba-af6e-ce056b064e3e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Todd Geist
geist interactive
805-419-9382
GoDraw - Draw on Photos with FileMaker Go

jeremy...@gmail.com

unread,
Jul 5, 2013, 6:17:58 PM7/5/13
to modular-...@googlegroups.com
I'd also rather not have #AssignGlobal, but other folks were using the # functions to set global variables, and I decided that a separate function would be a better way to handle that than allowing the #Assign function to have such a large side-effect without some mention of it in the function name.

Daniel Smith

unread,
Jul 5, 2013, 6:40:55 PM7/5/13
to modular-...@googlegroups.com
I like it!

After using these functions for some time, I have almost never used the ErrorGetCodeFmp or ErrorGetCodeApp CF's, so I think omitting them is also a good idea.

I prefer your #NewError over my ErrorDataApp function. My idea was that each user would modify the ErrorDataApp CF to meet their needs, but like you said, it's better to do that modification in a wrapper function/script.


As discussed briefly before, I think we have to be able to generate an "fmp" error, rather than only testing Get ( LastError ). As these functions are defined, it could be done with the #NewError CF, but the error text would need to be set manually. Personally, I would prefer that the "errorText" of an "fmp" error to always match the description of that error, as defined by FileMaker. That's not easy to do using this method, though.

FYI: I just looked at a solution I've been using these CF's in and found that I used my old ErrorDataFmp ( theErrorCode ) CF 100 times and 98 of those times the parameter to it was Get ( LastError ).

Does anyone think it's worth revising the #GetLastError function to take a parameter? If so, what would it be called?


I like the idea of a "note" parameter and think it's inclusion is worth discussing. Currently, I manually add a "section" to the error data like this:
#GetLastError & # ( "section" ; "Create Invoice: commit record" )
That isn't difficult, but here are the issues I see using this method vs a "note" parameter:
  1. The name of the name/value pair is not standardized.
    Sadly, I have to admit that I have used up to three different names within the same solution for the same purpose, simply because I forgot what I used before, didn't write it down, and didn't want to take the time to look it up.
  2. Adding a "note" parameter to these custom functions encourages people to use this feature
    Since I think this is a useful feature that provides valuable feedback about the error, I think this is a good thing.




 

--
You received this message because you are subscribed to the Google Groups "Modular FileMaker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modular-filema...@googlegroups.com.
To post to this group, send email to modular-...@googlegroups.com.
Visit this group at http://groups.google.com/group/modular-filemaker.

Daniel Smith

unread,
Jul 5, 2013, 6:44:39 PM7/5/13
to modular-...@googlegroups.com
I have never used the #AssignGlobal CF, and don't plan to. Perhaps we could find someone who does use it to chime in with their reasoning for doing so?  (then we can shake our finger and tell them how horrible they are, ha!)


--
You received this message because you are subscribed to the Google Groups "Modular FileMaker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modular-filema...@googlegroups.com.
To post to this group, send email to modular-...@googlegroups.com.
Visit this group at http://groups.google.com/group/modular-filemaker.

Todd Geist

unread,
Jul 5, 2013, 7:12:20 PM7/5/13
to modular-...@googlegroups.com


Daniel Smith wrote:
As discussed briefly before, I think we have to be able to generate an "fmp" error, rather than only testing Get ( LastError ). As these functions are defined, it could be done with the #NewError CF, but the error text would need to be set manually. Personally, I would prefer that the "errorText" of an "fmp" error to always match the description of that error, as defined by FileMaker. That's not easy to do using this method, though.
We could modify #NewError to include the fmp error text if you happen to set "fmp" as the errorType. ( I know that would be the conversion from code to text in two CFs.  I am ok with that in this case )

That would mean that you could generate an FMP error with #NewError(301; "fmp"; "")

Todd

Daniel Smith

unread,
Jul 6, 2013, 3:12:06 AM7/6/13
to modular-...@googlegroups.com
I like that idea.
--
You received this message because you are subscribed to the Google Groups "Modular FileMaker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modular-filema...@googlegroups.com.
To post to this group, send email to modular-...@googlegroups.com.
Visit this group at http://groups.google.com/group/modular-filemaker.

Todd Geist

unread,
Jul 15, 2013, 7:59:18 PM7/15/13
to modular-...@googlegroups.com
So can we move forward on building this module???  I think one of you guys ( Dan and /or Jeremy ) should be the author, since the two of you put the most time into it. I would like to feature this module at DevCon as an example of a module put forth by the community ( ie not me ).  And DevCon is fast approaching.

I'd say version 1.0 can just include the #Family (perhaps with the #FPath function ) and thats it. Lets leave off any discussion of building a core mFM module for later. 

What else do we needs doing to make this public?

Todd

jeremy...@gmail.com

unread,
Jul 16, 2013, 10:57:25 AM7/16/13
to modular-...@googlegroups.com
I'm working on writing the documentation from FileMakerStandards.org into the test file itself. Once I'm done with that, I'll post it to ModularFileMaker.org.

Dan and I have discussed using the FMS repository as the version of record. Since the FMS discussion seems to be leaning towards accepting modifications as pulled forks, perhaps that's the way to handle adding the #FPath function.

Todd Geist

unread,
Jul 16, 2013, 4:10:08 PM7/16/13
to modular-...@googlegroups.com
That works!

Thanks

Todd

jeremy...@gmail.com

unread,
Jul 20, 2013, 3:03:14 PM7/20/13
to modular-...@googlegroups.com
To keep folks in the loop, my pull request to the filemakerstandards repository is pending approval. We're giving everyone a few days to scrutinize it.

Todd Geist

unread,
Aug 3, 2013, 12:55:23 PM8/3/13
to modular-...@googlegroups.com
So it doesn't look like any of the Error functions made it into this module. Is that intentional?

If so then I will bundle my functions into an extension module

Todd

jeremy...@gmail.com

unread,
Aug 3, 2013, 2:19:53 PM8/3/13
to modular-...@googlegroups.com
The first step was to wrap-up the pieces already in the FileMakerStandards.org version in module form. Adding the Error functions deserves a separate merge, I think, which may as well come from you.

Daniel Smith

unread,
Oct 11, 2013, 4:10:44 PM10/11/13
to modular-...@googlegroups.com
FYI: I've been working on creating a set of Error functions, I'm going to use them for a while before I submit a pull request for them.

Todd, were you going to submit a pull request for the #FPath function? I'd like to modify the examples in my JSON module to utilize that function for retrieving values.

Todd Geist

unread,
Oct 11, 2013, 8:34:46 PM10/11/13
to modular-...@googlegroups.com, Daniel Smith
Hey Dan,

I am headed out of town for a week, tomorrow morning.  but I sent a Pull request in for FPath.  

Thanks

todd



Please feel free to work with those until I get back and we can do the pull request

On October 11, 2013 at 1:10:46 PM, Daniel Smith (dansm...@gmail.com) wrote:

FYI: I've been working on creating a set of Error functions, I'm going to use them for a while before I submit a pull request for them.

Todd, were you going to submit a pull request for the #FPath function? I'd like to modify the examples in my JSON module to utilize that function for retrieving values.

Todd

-- 
Todd Geist


Daniel Smith

unread,
Oct 25, 2013, 8:55:42 PM10/25/13
to modular-...@googlegroups.com
FYI: I updated my error custom functions, and am trying to spark one last discussion about them before making them official: http://filemakerstandards.org/display/props/Error+Information+tracking?focusedCommentId=10649602#comment-10649602

Once finalized, do you think they should be added to the #Parameters module? Or a module of their own?

Personally, I am fine with them being in the #Parameters module because I plan to always use them for error trapping, but then again I think I'm biased so it's probably best to ask someone who may be less inclined to use them.

Todd Geist

unread,
Oct 25, 2013, 9:30:52 PM10/25/13
to modular-...@googlegroups.com, Daniel Smith
I am ok with them being in #parameters. But I think it is worth thinking about making them separate. Is there any value in making them separate?    Could somebody adapt them for a different name-value pair scheme?  Would that be good or bad?


From: Daniel Smith Daniel Smith
Reply: modular-...@googlegroups.com modular-...@googlegroups.com
Date: October 25, 2013 at 5:55:44 PM
To: modular-...@googlegroups.com modular-...@googlegroups.com
Subject:  [mFM] Re: FileMakerStandards.org # functions as module
FYI: I updated my error custom functions, and am trying to spark one last discussion about them before making them official: http://filemakerstandards.org/display/props/Error+Information+tracking?focusedCommentId=10649602#comment-10649602

Once finalized, do you think they should be added to the #Parameters module? Or a module of their own?

Todd

Daniel Smith

unread,
Nov 14, 2013, 7:41:43 PM11/14/13
to modular-...@googlegroups.com

Matt Petrowsky's comment at filemakerstandards.org made me think that the Error functions should be in their own module and include a method of logging name/value pair data to a FileMaker table.


My first step will be to add the custom functions to filemakerstandards.org's github repo without a sample file to go with them. Eventually, I'd like to add logging scripts/table to a sample file and package it all up as a module, but I have some issues to resolve with my logging routine before I do that.
Reply all
Reply to author
Forward
0 new messages