Database Reference
In-Depth Information
FREQUENTLY ASKED QUESTION: SEPARATING FORMATTING FROM DATA
Why would a math major like me use lowly, layout-based conditional formatting when I can make a
whole bunch of very cool, very complicated calculations using text formatting functions?
It's true that conditional formatting doesn't give you a whole bunch of options that you don't have
with text formatting functions. However, you do get a giant leap closer to something that's been dif-
ficult to do in FileMaker—separating the presentation layer from the data layer of your file.
In programmer-speak, the
presentation layer
is anything having to do with showing your data. It's
the layout and all the stuff you put on a layout to make your data easy to understand. Even the fact
that you can move fields around in relation to one another is part of FileMaker's sophisticated
presentation layer. Boldface fields, portals, buttons, and web viewers are presentation tools, as well.
Custom menus and tooltips, which help you help your users work with their data, are also forms of
presentation.
The
data layer
is just what it sounds like—the tables and fields of actual information. Most calcula-
tions also fall onto the data layer. For example, when you multiply the Quantity and Price Each
fields together, using a calculation in the Extended Price field, that's the data layer.
So is adding a five percent surcharge to late payments.
Adding another five percent 30 days later, when those deadbeats have come up with more excuses,
is still the data layer.
But when you use number formatting to display the results of any of those calculations with dollar
signs, commas, and decimal places, then that's presentation-layer territory. And if you use a text
function to display the late penalty in red, boldface at 18 points, then you're treading in the presenta-
tion layer, even if you use a sophisticated calculation to see if the penalty is due before you apply
the format.
Furthermore, when you rely solely on calculations for formatting, you've got to add more
complex-
ity
to your calculations to
simplify
some layouts. Say you use a text formatting function to display
unpaid invoice totals in red after 30 days. The field
always
displays the red text where appropriate,
even if that's not the purpose of the layout. For example, if the marketing department needs a list of
invoices over $500 to decide who gets special offers, the red invoice amounts make no sense—and
may violate customers' privacy. But if you separate presentation and data by using conditional
formatting, you can apply the format on a layout-by-layout basis. So all in all, it makes life easier
down the road if you confine your use of calculations to mathematical operations
on
your data and
use conditional formatting to handle the display
of
your data.
So is one method better than another? Probably not. But when you look at other developers'
calculations, you may see all these forms, so it helps to know how they work. If you're the
only developer working on your files, then you're free to use the construction that makes
most sense to you. But when you develop in a team, you might want to develop a standard
