Application Design Style Question

[Ray Gans]

What is the "recommended" way to create layouts and scripts for an application consisting of a major file and one or more dependent related files? To be specific, File A is a movie database with information about particular movies. File B is a related file (to File A) that holds information about owned media (DVDs, tapes, laserdiscs, etc.) where each media has a specific owner. File C is a related file (to File A) that consists entirely of ratings by various people who watched the movie. File B and C are independent of each other.

Assuming File B and File C information is too large to conveniently fit into a portal and must be entered on separate layouts, my question is whether the generally accepted "best" way to design these scripts and layouts is to:

1) edit/add info to layouts of global fields in File A and update/add them to File B (or C ) via scripts

-or-

2) invoke scripts and layouts in File B (or C) to edit/add the appropriate fields there

In other words, do data entry in File A layouts for all files, or do the data entry in layouts within the File being updated.

I've always chosen option 2 in other applications, but it can be awkward (e.g., I must copy the movie ID from File A and paste it into the related File B or File C key fields in order to link them). After seeing some of the traffic on this site, I wonder if I've been doing it all wrong?

[Henry]

If your solution are run on a network, i think option 1 is recommended. Global field is update after user click a done button and allow many user use the same field, it can avoid the problem which only allow one user edit the record and also the auto generate no issue.

Regards,

Henry

[dbruggmann]

For a multi-user solution you should go a step further and create a fourth file for input and viewing all the data from files A, B and C (with global fields and scripts for updating). Only this one then would be installed on the client machines.

Also, this way you have (almost) only to alter one file, if you want to change the interface later.

[Charles Delfs]

Hold on,

How can a related file have too much information for a relationship.

Extra Files? just sec. by seting up a relationship and populating a layout with related fields you don't create a portal but a whole layout that is effectivly the related database.

Charles

[Fenton]

There is no "this is the right way to do it," three answers, 3 different methods (though the "use global fields for data entry" and the "use an entirely different file" both use global fields.

Much depends, as you say, on what fits and seems logical on a data entry layout. That is the most important thing, from the user's point of view. How you do depends on very many factors; and it to some extent both a matter of preference, and arbitrary.

It sounds like to me that you have a fairly simple database, not a lot of files, not a matter of life and death.

If the portals for B and C don't fit on one layout, you might just want to put each on its own layout. That's one solution. This lends itself well to the "tabbed" interface, a row of tabs at top for the different layouts.

Another simple solution is to jump to files B and C to do editing and viewing of details, on Form view layouts.

This requires some scripting, of new related records especially (since there's no record to go to at first). Which involves learning to pass ID values in global fields between files (easy) and call an external script to create the new record.

Navigation happens via Go To Related Record ["Relationship"], then a call to an external script, to Go To Layout ["Whatever"].

How you arrange, zoom/not zoom windows is partly platform specific (Macs tend to leave windows alone, Windows wants to either zoom or maximize all open windows at once).

It's all fairly basic FileMaker. But there's more than 1 way to do it.