Great points. Yes -- my guess would be that, out of all the options mentioned so far, the button bar would be the heaviest in terms of data stored in the layout to define its rendering.
Earlier in this thread I neglected to mention that I used to love using the placeholder feature for this purpose, and, even when button bars were added to FMP, I still preferred it for a while, because I felt it would probably be leaner.
The progression of my own personal use of these techniques has gone something as follows:
Using merge variables, as you've described:
- I believe I used the Hide Object When calculation to set the variable's value, instead of a conditional formatting calc.
- I never did this in the body of a list view layout or in a portal row, because I did not find it to be 100% reliable.
- I pretty much used it only in non-mission-critical settings, because I was always concerned that an under-the-hood change to how FMP renders layout objects would break the technique, and I didn't want another developer to inherit that from me.
Using placeholder fields as you've described:
- When the Placeholder feature was introduced, I was crazy with delight because it felt like a solid way to have a layout-based display calc, that would work in form view, list view, and portals.
- Basically, I thought it was a "sleeper" gem, and I was surprised not to hear about many other developers using it in this way.
Then the Button Bar was introduced:
While I acknowledged that this was one more option at our disposal for a layout display calc, I did not warm up to it at first, because I did not like the idea of having to use a button object to display my text when I did not need a script attached. It went against the grain of my sense of efficiency, and part of this was because, again as you've suggested, it felt less lean to me than a placeholder field (though I never checked).
With time, I eventually switched to using a script-less button bar segment, my reasoning being:
- It did not require an empty field to attach the display to.
- Conditional formatting was less cumbersome than with the placeholder field.
- I was willing to consider the possibility that, while the button bar is probably a heavier option than the placeholder in terms of defining the object on the layout, the difference between these two objects might not be significant enough of a performance aspect to pursue if I did not have a high count of them on the layout.
Another aspect of these techniques that I consider:
A measure of how widespread the need for the displayed calculation is.
If I have some kind of calculation function that I am only going to need to display on one layout of a large solution, I am more likely to want that calculation out of the schema, and coded closer to (or at) the layout level.
If I have the same calculation function but I need to display it on many layouts within the solution, I am going to want to centralize that function, and not code it into every button bar.
In such a case I might still use a button bar calc, but I'd centralize the function's logic into a custom function.
If I am on a team that values older and simpler approaches, I might concede that it would be less cryptic for the next developer if I don't use a button bar that points to a custom function -- perhaps I could live with the calculation in the table, provided that it does not store a large amount of text that makes the record too heavy to pull across the network. Doing so would not be my first choice, however.
Personally, I am partial to the custom function approach:
Many examples that I have for this sort of feature are of the nature where a combination of status codes stored in the table is being translated into some more meaningful text to display to the user. I'd very much rather have that sort of "translation" logic outside of the schema, and instead keep it in a custom function where I find it easier to maintain, and also where it has the sort of separation from the data that I appreciate.
All the best & thank you for chiming in,