Peek A Boo Body Report Technique/Demo File

I have been meaning to post a demo of this technique for a while now. I haven't come across other demo's using this technique, not to say it's not out there but here it is. I hope someone finds it useful.

What's going on with the Demo?
Use a single layout to display a report that shows Contact data in many different ways. We are all familiar with sub-summary layout parts displaying in browse mode (YAY), but the twist here is that we don't have a BODY LAYOUT PART on the report. YET this report can show or hide detailed data that would typically be shown in the body part of a report layout. The simple trick is to change the BODY layout part to a sub-summary based on the ROW ID. When we want to SHOW the body, we sort by the primary key and viola you have a PEEK-A-BOO BODY layout part. Create a couple or more filters to change the way the report is viewed and create as many sub-summary parts to match sorts. Adjust the layout so it looks good when sorted various ways, it is a bit compromised but pretty neat.

What are the moving parts in this demo?
1 - Table (Contacts)
1 - Layout with 4 Sub-summary layout parts (Sales, State, City, ID).
2 - Global fields for solution users to set the REPORT STYLE and the REPORT FILTER, with script triggers attached to run ON OBJECT MODIFY
1 - Script "Apply Report Style, Filter and Display the Report" triggered from the above global fields

And a little bit of conditional formatting to make it all look nice.

Why is this cool?
Because you can have 1 layout that does a ton. This means a single layout to maintain over time. Somewhat scalable, you can always add more sub-summary layout parts to display/group your found set of records based on different types of fields, or even calculated fields.

How to use the report.
This demo file defaults to all the records in this sample database. Toggle the Report Type from "Summary" or "Detail" AND then try the Filter options, in combination with toggling the Report Type back and forth from Summary and Detail. This should give you an idea of how the report works. Crack open the layout and see how that works.

Demo_Peek-A-Boo_Report.fp7

Server Side Scripting With A Dedicated Execution File

I am still wrestling with a 100+ legacy database solution. I haven't been able to consolidate or re-write yet but have been slowly, version by version starting to deploy new Filemaker features. One thing I did, was set up a Filemaker file who's sole purpose is to call and execute server side scripts.

Now that we have script triggers firing off, God knows where (on file open, on layout load, on object enter... for example), you really have to make sure that stuff isn't firing off for a server side script and you don't always have time to review all of the dependencies of executing scripts from a given database file. If you do and do not do your homework, you may be calling incompatible script steps which could hang your server script or create loads of errors in your logs.

I wanted a simple, fast and safe way to call scripts across the 100+ file solution and be sure that on window open scripts didn't fire. Typically, the on file open scripts tend to do things like call custom menu sets or other non-server-side script compatible steps. So, knocking those out of the picture this way was a big plus.

Setting up my server side scripts to run from the dedicated execution file, each call remote scripts through out the solution, seems to be doing the trick. When performing REMOTE scripts the remote file ON OPEN scripts don't run.

When writing the worker scripts, that live in the remote files, I will typically create a clean layout - one that that has no bells and whistles attached to reference.

I also like the fact that you can go to the dedicated script execution file and see all the various server side scripting routines at play or in development. Also, a good place to document the scripts and organize in folders. I like to use a PRODUCTION folder and TESTING folders. It's also cool when you have more than one developer. Using a consistent naming scheme for server-side-scripts located across the 100+ files in the solution will make it easy to locate them in a pinch on a file by file basis or even from a DDR perspective.

Not everyone would want to have an extra file in their solution for this purpose but in this use-case I have 100+ what's 1 more, to me nothing. It's kind of nice quick way to move ahead when working on a massive system that sprawls over a decade of FM versions and code. It does require following a development process for server side scripts:

1. Use a naming convention for your worker scripts, so you can find them
2. Always run your worker scripts off lean utility layouts that don't have script triggers
3. Make sure you aren't calling other scripts that will do incompatible script steps or incidentally reference layouts that call scripts that do incompatible things
4. Create a script in the dedicated execution file to call/RUN your main worker script

I'm working on a new server side script and was reminded again that this method I had come up with a while ago, does seem to be working well. I avoided some headaches of having to review what on open routines were doing that could cause me pain and it actually saved me some time. An idea I tried a while ago is paying off today.

Playing with 0 as Parameter in the Date function

I recently came to understand how using 0 in the month or day parameter of the date function can be pretty handy. I admit this is a basic idea to many but if you don't use it I figure this insight might get the wheels turning.

This example shows how to calculate the last date of the month from any supplied date.

Let ([

    // Put your date or date field here
    theDate = "10/30/2010";

    // Get last date of month base on theDate
    lastDateOfMonth = date ( month(theDate) + 1; 0 ; year(theDate))
];
    lastDateOfMonth
)

or this example which results in the last date of the year prior...

date ( 0+1; 0; 2010) // last date of year for year 2010

Notice the 0 and how it's behaving when used inside the date function. I realize grabbing the last date of any year is easy to calculate in other ways, it's not the most intriguing use case but I wanted to demonstrate the behavior of using 0 as month.
Good stuff. So I plan to play with 0, + and - in functions more often.

Hello Blogger

Well, here I am trying blogger now. Still trying to find the most comfortable blogging space. I hope to post mostly Filemaker things here but who knows. I seem to change my mind often enough.

Today was a good day, I'll start with that