Managing dozens of similar layouts in many files

[kennedy 0]

I've designed my fields and relational structure.

I've designed my basic tabbed navigation that will be common across all layouts.

Now, what's the right way to set this up such that it is easy to manage??

Is there any notion of a template or master layout, such that if you make changes to it, all the other layouts based on it get those changes automatically?

Or do I need to just be prepared to cut-n-paste to each file?

If the latter, are there any key things to know regarding cut-n-paste?

For example, if the buttons and scripts are assuming certain field and layout names, do I need to make sure those each exist prior to cut-n-paste of the layout elements? Or will it just leave them as "dangling references" that I can fill in later?

Other tips in managing dozens of similar layouts?

Any books or websites or Forum Threads that specifically address this?

(I can't seem to find anything about it in the FMP Help.)

Thanks!

P.S. I was originally going to post this in the "Layouts" group; but there isn't one. What is the right group for layout-specific questions? I chose this group, since the issue of going across files is primarily critical with relational databases.

[LiveOak 1]

To answer the easy question first. It is best to setup fields before you paste a layout. That way, if the field names match, you won't have to go back an connect fields.

Some of the most current thinking is to try and separate the data layers and business logic layers from the user interface. At DevCon several sessions presented a "single file interface" where all layouts are in one file with the data in separate files with esentially no scripts and layouts. It's more complicated to set up one time, but supposedly has advantages in maintenance of layouts and scripts.

I'll see if I can dig out some example files from the conference CD. If you don't hear from me, bug me in a day or so by message or email.

-bd

[kennedy 0]

Interesting... I hadn't even thought of that possibility... but it makes sense.

But that raises the question... if all your layouts are in a single file, is there an efficient way to maintain 20 layouts that are all very similar? Can you somehow define one layout based on another, so that later when you change the "base layout", all the others get the changes?

(If there is such a mechanism, then there would be even more justification for pulling all the layouts into a single separate file for layouts!)

Thanks.

[Of course, that single-file question doesn't really fit this forum... which forum does it belong in?]

[CobaltSky 14]

I'm not sure whether the dozens of similar layouts you're referring to are for reports, however if so, and it is mainly the content and headings which differ, it is possible to re-use a single layout for a number of quite different reports (including reports which draw data from other files).

A way to do this is to create a pair of fields - one global text field and one calculating field - for each field required on a report. In addition, create a global text field for each major report text element (eg main heading etc).

The calculation fields will be placed on the report in place of the fields which you wish to display, and the corresponding global fields will be used in place of the field headings. The simplest method to set up the calculations is to use the GetField( ) function which was introduced with FMPv5.5. You can use the formula

cReportField1 = GetField(gReportField1)

where 'cReportField1' is a calculating field which is paired with the global field 'gReportField1'. If you are using v5.0 or earlier you will instead need to hard code the fieldnames into case statements within the calculating fields, along the lines of:

code:

Case(

gReportField1 = "ClientName", ClientName,

gReportField1 = "ClientState", ClientState,

gReportField1 = "ProjectTitle", ProjectTitle,

gReportField1 = "ProductDescription", ProductDescription,

gReportField1 = "AwardName", AwardName, "")

Once all your global fields and calculating fields are in place on a layout, you will need a script for each report which places the fieldnames for each column into the appropriate gReportFieldN global field. The calculating fields will then automatically display the corresponding field data (providing the calculation result type matches that of the asigned field). Similarly, each script can place appropriate text into the global fields which provide the report heading text etc.

Ideally the script should call a series of Set Field steps to populate the necessary global fields prior to sending the report to a printer (or to an on-screen preview etc) and should conclude with a further series of Set Field steps which clear the global fields again.

In this way, the specifications for each report can be determined by script, re-using the same layout many times, rather than by maintaining a large number of layouts of generally similar appearance.

An adaptation/extension of this approach can be used for other types of layouts (eg other than reports), including alternative button labels, appearance and functions etc, but I'll that to your imagination

[kennedy 0]

I'm not sure whether the dozens of similar layouts you're referring to are for reports, however if so, and it is mainly the content and headings which differ, it is possible to re-use a single layout for a number of quite different reports (including reports which draw data from other files).

I will have to deal with the reports case in coming days, but my current primary concern is actually my primary interface... a tabbed interface. The tabs on the top and the navigation controls underneath the tabs are exactly the same for every single layout. I can cut-n-paste it to each... but then later when I decide to change a tab, I get to cut-n-paste it to each again. And so on.

To use PowerPoint or Dreamweaver as an example, it would be nice to be able to define a master page on top of which the individual pages are built... then I just edit the master page... and all of them get the changes.

Any equivalent here in FMP-land?

If not, what's state of the art practice? Cut-n-paste?

[CobaltSky 14]

I'm afraid there is no equivalent for layers or master pages in FileMaker.

However if you create global text fields for your tab names (and perhaps global container fields for tab graphics etc), you will then be able to change the labels or graphics in those fields and the change will be reflected everywhere they appear - on any number of layouts.

It's a different approach, but may get you some of the efficiencies you're looking for.

[kennedy 0]

However if you create global text fields for your tab names (and perhaps global container fields for tab graphics etc), you will then be able to change the labels or graphics in those fields and the change will be reflected everywhere they appear - on any number of layouts.

Yes, that will cover some of the cases. So, how do you share global fields across files?

Related Q: How do you share scripts across files? I guess you could just make external calls to the "master page" that holds the scripts that in-turn make external calls to the files that I am trying to bring up.

Thanks for the insight.

[djgogi 0]

I think that you should separate GUI from data by creating external Resource and dictionary files; first containing graphics and second one containing localized string for your solution.

Than access them thru relationships.

As far concerning scripts instead of sharing them you could use flag and case scheme like this:

if[flag=1]

perform Script Script1

Exit Script

End if

if[flag=2]

perform Script Script2

Exit Script

End if

...

if[flag=n]

perform Script Scriptn

Exit Script

End if

Dj

[CobaltSky 14]

Question 1 So, how do you share global fields across files?

The accepted technique is to create a Constant key field in each file (eg a stored calculating number field with a formula of 1) and create a 'global' relationship which matches these fields to each other. That relationship can be used to place the global fields from one file (eg the main file) on layouts in each of the files.

Question 2 : How do you share scripts across files?

Yes, the scripting architecture allows for sub-scripts and external sub-scripts. The methodology you'll need is one where a main script on one of the files calls one or more sub-scripts in other files.

A variant technique is a relay structure where each script calls another script as its last step, thus passing the activity along to yet another file. In this relay or 'chain' action, a single procedure can be sub-divided into several scripts placed appropriately in different files (according to the optimal location for performing the functions associated with a part of the procedure). Each script is linked to the next via a closing Perform Script [External] call, so when triggered, they operate as a single sequence.

[kennedy 0]

Ray, I think I'm going to owe you dinner pretty soon...

The accepted technique is to create a Constant key field in each file (eg a stored calculating number field with a formula of 1) and create a 'global' relationship which matches these fields to each other. That relationship can be used to place the global fields from one file (eg the main file) on layouts in each of the files.

Let me make sure I have this right:

1) I create a file "Globals.fp5" that has all my shared globals. It has a single non-global field called "Hook" that is a stored, indexed, calculation of numeric value 1.

2) In all my other files I define a global field "gHook" that is calculated numeric value 1. And I define a relationship "Globals" to "Globals.fp5" matching gHook to Hook. No storage costs in that.

3) Now from all my other files I can access all my globals via Globals::whatever.

Right? Cool.

Each script is linked to the next via a closing Perform Script [External] call, so when triggered, they operate as a single sequence.

There's nothing special required there, right? So, when FMP sees a script whose last call is a Perform Script, then it simply chains rather than nesting? If I have a long series of these, will I have a bunch of scripts on the stack waiting for their subscripts to complete, or will only the last one be there?

Thanks!!

[CobaltSky 14]

Let me make sure I have this right:... 1)... 2)... 3) Now from all my other files I can access all my globals via Globals::whatever...

Right? Cool.

Yes, that sums it up beautifully

...it simply chains rather than nesting? If I have a long series of these, will I have a bunch of scripts on the stack waiting for their subscripts to complete, or will only the last one be there?

No, each script will exit from memory as soon as it makes the call to the external sub script (providing this is its last step).

[LiveOak 1]

If the layouts are very similar, one option is to use only global fields for both "fields" and "field names" on a single layout. Global containers can be used for any buttons. This way you only have one (of a few) layouts that are configured dynamically for whatever you are displaying. You can use a separate file to keep track of each dynamic layout, it's name, use, the contents of each field label, and the contents of each button. The actual field labels and graphics could be stored in a third file. This work make maintenance about a organized as it gets.

-bd

[kennedy 0]

That's an interesting thought... my forms won't be that similar (except for the header tabs and controls)... but my lists, of course, are very similar in look. Basically, every list will look like the graphite.fp5 list layout from layoutmode.com...

So, how hard would it be to define the layout once with N columns, and then define global variables that specify:

1) Column Label (easy)

2) Column field

3) Column width (possible?)

4) Column sort (I'll have sort buttons at the top of each column)

5) Column hidden (possible)

If I could set that layout up once, and then just fill in the above global variables for each layout I want... oooo, that would be sweet!!

Anybody seen a public template/db that does similar?

Thanks!!

[Fitch 169]

Take a look at Smart Tabs , it sounds pretty close to what you want to do.