This proposal is based on the development of a FileMaker solution which caters to multiple technologies. (e.g FileMaker client/server vs. web vs. mobile)

Distinct files for each technology

Essentially, the best practice is to use a separation model with the following files. Important Note: the names of the files are not explicit. They are simply representative of what technology each file would interoperate with. Additionally, there is no limitation to the number of any given type of file. For example, your solution may use one (1) data file, three (3) different FileMaker interface files, based on departments or some other classification, and one (1) FileMaker mobile file.

DataFile{n}.fp7
FileMakerInterfaceFile{n}.fp7
FileMakerIWPFile{n}.fp7
FileMakerCustomWebFile{n}.fp7
FileMakerMobile{n}.fp7

Note: the {n} above implies that multiple files may be used in your solution.

Beyond the number and interconnections between Data files used to store centalized solution data, one (or more) files can be used for each distinct technology.

The primary reasoning behind this convention is to separate application logic layers into distinct files. This not only compartmentalizes them, but facilitates more coherent and simplified organization.

Using external data references, any one file can certainly call any other file to access common or shared functionality (dry practices).

Shortcomings

The above development model does have a few shortcomings. One of them is the required duplication of Security settings when any one given setting may work for all files. It would also be easier to manage account authentication via FileMaker's support for external authentication.

  • No labels

10 Comments

  1. I like the general idea as a Best Practice, but I think we could use more details on how functionality might be shared (or not) between files. Sharing table occurrences is cheap, performance-wise; calling each others' scripts is much more expensive (and usually just plain ugly - there are reasons we aren't still using FileMaker 6), especially for mobile WAN deployments. What makes an application helpfully organized for developers or a quality experience for users are not always the same thing, and different ways to share functionality between files reveals the difference like nothing else. I'd like to prioritize user experience over developer experience.

    1. From my limited experiences, the interaction between disparate technologies, when it comes to the files, would be limited. For example, the UI I'd build for a Go version of a solution wouldn't use too many of the scripts found within the FileMaker client/server file.

      The web files I've built require much more rigid attention because you're coding things into PHP which means you can't just go in and change the name of a table occurrence like you can with a client file.

      Are there specific cases you're thinking of where calling scripts in another file is THAT bad? Granted if the called file isn't open... Or heaven forbid it's a Go file calling a client/server file on a different machine over the Internet! I would hope a developer worth his/her salt would know that would suck.

      The suggestion is more about developmental approach attempting to create clear lines between technological application. It's not proposed as an absolute. There are always conditions which dictate deviations. I'm always about user experience!

      1. The called file not already being open when called in Go was exactly the kluge I had in mind. A common record creation script might be an example of functionality I'd rather replicate in each interface file than share between files. This is the kind of thing that would be in an intermediate application logic layer in another development platform. For FileMaker, it's better to plan for each functional user (in the use case sense, not necessarily the person sense) to touch as few files at a time as possible, even if some functionality has to be replicated and kept in sync.

        1. The kluge can be prevented using techniques I'm discussing elsewhere.

          A client doesn't load anything in a related .fp7 file that isn't immediate to the default layout such as scripts, related tables or files used on the layout in question. Simply having an EDS reference to FileB.fp7 doesn't create extra processing weight until FileB.fp7 has a default layout relying on scripts or objects attached to entities that already haven't been loaded in FileA.fp7 called by the Go client. This can go so far as which scripts and layouts are available to the default layout accessible via the Scripts menu item or Layouts drop down menu. I just discovered this hurt over the weekend - it was truly eye opening on where resources are being introduced to the client at hand on opening a file.

          1. Startup isn't the only situation where interacting with other files can become a burden. Data and value list references between files are relatively cheap. Running a script another file requires a new window, which is awkward at best, even with a file optimized to have a low-impact startup.

            There's also a functional independence concern with multiple interface files which will sometimes conflict with the DRY principle.

            These kinds of concerns are why I think this proposal could stand to flesh-out a bit more the details of what files do and don't share, and how. TOs? Great. Value lists? Dandy. Security? Some replication is technically necessary. Scripts? I'd rather avoid it where I can.

            How about this: chatter between interface and data files is fine, but between interface files is not?

  2. I like this one. It's currently a long term goal I'm working on to do this exact thing in my main solution I develop for.

    Regarding shortcomings, yes it's a bit of a pain to have to duplicate some security settings it also ensures that you're not allowing access in files that don't need it at all, i.e., fmpxml access in the client file or fmphp access in the mobile file.

    We should extend slightly where there may be multiple main interface client files segmented by functional department.

  3. I think separating interface files by functional department is a fundamentally different approach from what's being proposed here. Perhaps a separate best practice is in order?

    1. I'm cool with integrating functional UI file differences into this proposal.

      I think the fundamental here is using the separation model to achieve compartmentalization. Personally, I'm not too keen on creating a ton of different pages for slight variations on something that covers the basics.

      You guys should feel free to append to these proposals. Hopefully, we can leverage all of our experiences to create the ultimate specs.

      1. OK, the easy fix I was looking for is instead of "FileMakerInterfaceFile.fp7" I was looking for "FileMakerInterfaceFile{n}.fp7" as per the data file spec.

        I'll append my request in the page body...

        1. Perren, you can rewrite the spec to read better if you feel the need. You can add the {n} directly to it.

          Each page on the wiki has revision history and we can always revert.

          Of course, it is within proposals. (smile)