We have libraries of custom functions and make heavy use of them in customer solutions. We update our libraries on a regular basis. We never had to update client libraries… that is until last week. And what a painful process it is for us.
FileMaker's implementation of the custom functions feature is weird to say the least. Unlike script editing, the interface is vastly different. Custom function definitions are displayed in modal dialogue boxes. Custom function definitions can not be printed. Custom functions can not be grouped into folders. Imports are not smart. Edits are limited to one custom function. Side by side comparison or copy and paste is not possible. All in all, the UI is very limited and limiting.
I am looking for any help, tips, tricks and hard earned lessons so that we can avoid or minimize this fiasco in the future.
I do agree, the cf GUI isn't consistent with that of script-, field- and other formula editors. Numerous Feature Requests go back over 10 Years.
For my solution, update deployment just happens by replacing the primary file. That's where the cf's are and though, new cf's make their way to the customers solution.
Are you familiar with the Import function with the CF Manager? With it, you can "load" cf's from another Filemaker file.
This is one of the key reasons I use micro-services. They give you a single point of update for one FMP application or 10,000. Plus a service approach doesn't rely on FMP at all so you can use your own service methods (functions) with any other application that can issue HTTP verbs, too!
I cannot count on one hand the number of times I just updated a single micro-service method and every application that used it needed no configuration update and was instantly up to date.
With FM18 situation could be considered to be indirectly improved because while function replaces in many cases need for recursion therefor you can compose in data viewer and have many instances of FM clients with data viewers open additionally to modal custom functions editor.. (I admit typical FM workarounds but somehow works for me)..
The original post is not quite explicit in how the update was a fiasco. The limitations are mentioned, but difficult to interpret what ended up happening in the first place.
How many CFs had to be updated?
How many were interdependent?
Any CF that also needed to be re-named or change the number of accepted parameters?
How many files affected? One, 3, 8?
I assume here that using the DMT was not an option, please confirm.
Knowing what needs to be avoided will help provide what is sought after. Listing limitations is likely to result in a recommendation for a different platform or a hybrid approach to circumvent the problem (we know @anon45965781 stands in that corner).
I, too, was curious about the nature of the fiasco. Both from the standpoint of whether I might have a relevant tip to share, but equally, so that I could learn something from the experience.
Yes, we used the import feature of the manage custom functions dialogue box. I say it is dumb because it is only capable of importing new custom functions. It has no means of replacing existing ones. The script editor is the same. It would be nice to have an import feature that more closely resembles record import.
You are in love with micro-services and that's fantastic. We, on the other hand, are not and can not. We have requirements from time to time for off-line solutions. The internet fails from time to time and that can be a dealbreaker for mission critical solutions. I made the decision a long time ago to let FileMaker handle what it can and not seek the same functionality outside the application.
I did not explain our fiasco partly due to feeling sheepish at some of our obvious mistakes. I am not looking at what we did that needs to be avoided. I already did the post-mortem. Let me answer the questions all the same and shine a light on our naïveté or ignorance or hubris.
How many had to be updated? About 30 in a set of 113!
How many are interdependent? A lot! We group them according to dependence, however there are dependencies within function groups. It's a framework.
How many were renamed? Many! This was not much of a problem because we mapped the name changes prior to update.
Number of accepted parameters? That was our big mistake… and I should have known better, being a programmer in a number of other programming languages. This forced us to review pretty much every script and a number of field calculations.
Number of files? Thankfully only one! I wish FileMaker could do to custom functions what they do to custom value lists: the ability for files to use custom functions of other files.
That said, there are features other programming languages have that help manage groupings and code changes: name spacing; file-based organization; refactoring; grep-based search and replace of all code. FileMaker has none of these. All custom functions are stored like Lego in a 32 litre bin. Good luck finding a unique piece!
The two statements are (not completely I admit) contradictory:
Still, I'll say this and you can judge if it is any help:
updating select components of a live DB (scripts, CFs, field definitions, ...) is something I would expect from a patch tool (something that was still on the roadmap, last I heard about it). Will that behave how you need it to? Some people already are cautious about it, so it may not be that much of a game changer.
It does sound like you had all this working in a separate environment to start with, so the DMT may be the way to go the next time if replicating the changes involve too many manipulations.
I don't know about all the DDR tools, but fmPerception has something to identify CFs that rely on each other, grouping them in a "family". Having that charted ahead of time can proove helpful.
Changing the number of parameters in a CF is something that needs to be handled with extra care, as impact can be far-reaching (something you already outlined). Again, if the work is done ahead of time, the DMT can save you some trouble here.
Your last paragraph still points to out-of-reach items that are attributes of other platforms. I cannot help with anything like that. I know Julio Toledo has put together a project that is really "thinking outside the box", but from the lack of traction it is getting, I guess it is a bit too much outside the box (see Inzamelingsactie van Julio Toledo : Claris Studio IDE [Community Project] )
For finding anything in your Lego bin, assuming you know what you are looking for, the DDR should be your goto and not FileMaker per se (specifically if the native functionalities are not geared towards what you need).
I’m going to ask something that might be ridiculous and demonstrate how far I am from mastering FileMaker or Programming in general.
What if all the code of custom functions were the content of a field, and the parameter list in another field in a table, and the cf itself would call the content from these fields by ID ?
I often use the scripts workspace to code my cf and then copy paste it into the cf editor. So that would just be to paste in the table field.
I was trying some methods in aim to solve some data-separation demands. Just some thoughts:
using a separate table for formulas and use them with 'Evaluate (Formulas::MySpecialTask)
I doubt that this would work with rekursiv formulas?!
I successfully achieved a language related 'Substitute' for protocols I get in english language where some keywords should get "translated" into language the user has chosen (german, french, Italian). The formula was kind of:
. Evaluate ( Substitute ( MyTable::MyField ; Translations::substitutes_Protocol )
where the related field "Translations::substitutes_Protocol" was like
. ["dog" ; "chien"] ;
. ["room" ; "chambre"] ;
. …
I've already something like this in production. It holds rules for reporting and check of data integrity, it was not that easy to accomplish but with MBS-SQL-functions I was able to transfer a lot of calculation from script logic to dataset-evaluate-sql-update without context shift etc.
to cut this short: I think, a lot of stuff can be done like this
Holger
PS: Benjamin has pointed out one of the main ceveats for the none-english folks: everything should be done in english for evaluate and for the MBS-functions
Apologies for getting a bit off topic, but since this was addressed:
I generally would recommend to use english version only. When I'm in demand of german translation to help some friends with the D-A-CH Community, I find those @MonkeybreadSoftware AppleScript to launch a FM instance in different languages very helpful. Besides, it also allows to work in more than one FM instance simultaneously. It's a nice tweak to work in a formula editor (1 FM instance) and some other areas (other instances) at the same time. http://www.monkeybreadsoftware.de/filemaker/files/LaunchFileMakerInDifferentLanguages.dmg
Yeah, this has bothered me for a long time. I feel that what FM is really craving is a better package management system like npm.
The recent webinar suggests their adding modules, which look like they might be useful in managing sets of custom functions.
Otherwise, I've always wondered how easy it would be to create a macro/AppleScript to replace CF contents, a la the way Developer Assistant replaces text in scripts.
It looks like they are now calling this tool "Solution upgrade tool". Not a lot of documentation about it at this time, but I'm sure there will be enough interest from the community that some documentation will follow.
Updating custom functions with the Custom App Upgrade Tool will be great when everything is working. Automating the updating of custom functions will be great.
On a side note, having a testing file of Custom Functions will become even more important. It will be interesting to see how this develops over time.
