Leveraging Layout Variables
Within the world of FileMaker development, there are always those golden gems which become the hallmarks of "how to do something" - despite there often being more than one way to solve a problem. For managing lists of data, prior to the existence of the While function, the go-to custom function is CustomList. When it comes to variable output display using a portal you'll almost always reference Virtual List as the commonly understood approach.
When it comes to saving user state, there's always been a number of ways accomplish this. But, for my part, I'm going to declare Layout Variables as the way to solve many issues when it comes to saving user state in FileMaker.
While the term "Layout Variables" can apply to either locally scoped variables or global ones used within the layout, the concept is such that you're using variables to store things for the specific layout the user is on. When it comes to saving state, whether for the specific session or in order to persist, there has to be a simple and easy way to store, reference and retrieve these values and I think that solution is finally here. In this video, I showcase the Custom Functions and methods I use to implement Layout Variables.
If your FileMaker solution has a need to maintain state and make it easy to both store and restore global variables used for the user interface, then you simply must watch this video.
Comments
JSON
Did you consider a single $$LAYOUT[n] for each layout and storing all the variable data as JSON?
Certainly can be done that way.
Yes, you could use a single $$LAYOUT[n]. But the problem with that, as far as I see it, is that you now have all of your values globbed together within one variable. Whereas, with the suggested system, each variable can be seen within the Data Viewer without having to open up the one variable to inspect.
That is, unless I'm misunderstanding your question.
There are actually many different variations you could use on this theme. It's just a matter of preference. I don't mind seeing a lot of variables within the Data Viewer. But, I know some developers don't like that.
-- Matt Petrowsky - ISO FileMaker Magazine Editor
Great stuff. Simpler conditional formatting?
This is great. is there any reason for the toggle switch conditional formatting formula to be anything more complex than "True" if it hidden when false anyway?
Super Useful Concept
I would imagine this concept could be extended to include FOUND SETS of records as well.
Thanks,
G
Evaluate Function
A very useful concept. I note that the Evaluate() function is used in the start up script. Is there a reason why this does not pose a risk here but does so in other areas? If it is a problem, is there a work around?
Thanks,
Terry
Controlled Evaluation is Much Safer
The danger associated with the Evaluate() function comes from allowing the user to specify the string that will be evaluated. Since the user could specify anything, there's no way to know what the consequences are, and that is problematic.
If you can guarantee that the string being passed to Evaluate() contains known and tested code... well, it's about as safe as anything can be. So you would ensure the field in the user table is read-only for the user, and have a single script that executes with [Full Access] privileges to store a value in that field - call that script from any part of your solution that needs to store the data for the user.
--
Daniel Farnan
Ignorance is curable, not preventable
Evaluate Function
A very useful concept. I note that the Evaluate() function is used in the start up script. Is there a reason why this does not pose a risk here but does so in other areas? If it is a problem, is there a work around?
Thanks,
Terry
Evaluate Function
A very useful concept. I note that the Evaluate() function is used in the start up script. Is there a reason why this does not pose a risk here but does so in other areas? If it is a problem, is there a work around?
Thanks,
Terry