SeedCode Support Forum

For our solution, I am currently working with the following files:

INTERFACE
DATA
PHOTOS
DOCUMENTS

In the INTERFACE file, I have all the Layouts, and relationships for Layouts.
In the DATA file, I have all the Tables, Fields, and relationships for Calcs.

It seems silly to me that I'm having to create all relationships twice (once in the INTERFACE file for the Layouts, and once in the DATA file for the Calculations).

Am I missing something?

Nate

I don't think you're missing anything. Your data file will most likely have a relationship graph, albeit often a much simpler one, for supporting things like lookups and auto enter calcs.

The graph in your interface file will likely have some of these relationships also, but they may be augmented by filters, sorts, or other "presentation" kinds of things. And of course your interface file will likely have additional relationships just used for presentation.

As an aside, this needing of a relationship graph in the data file points out one of the "myths" (?) of separating interface and data: that you can rev only the interface file as you modify the software. While many changes are made just in the interface file, I'd suggest that most "new features" involve some change to the data side, even if its just creating a new summary field, changing Access Privileges, or changing auto-enter calcs.

(Of course there are still cool reasons for creating separate files.)

If you're just starting the solution, you may find it easier to build everything in one file to start. Then once everything is working pretty well, separate the solution into those files by duplicating the working file, removing the bits in each file that are not needed, and repointing the source TOs on the graph.

It's pretty easy to do, but hard to explain. Somewhere around here I've posted about this before.

Thanks John and Ender.

John:

I agree about your "myth" remarks. I discovered the same thing. If you don't mind, I would be very interested to see your quick list of "cool reasons to separate the interface and data", just in case I may be missing something else...

Ender:

That's exactly what I did. Now they're separated, and I'm improving the solution (a never ending process, of course).

Nate

Nate wrote:If you don't mind, I would be very interested to see your quick list of "cool reasons to separate the interface and data", just in case I may be missing something else...

In no particular order of importance...

• Getting away from the all-your-eggs-in-one-basket scenario you have when a 1 file solution goes south.

• Distributed development (with several interface files, one developer can work on one section while another works on other sections).

• Simpler graphs. We often have a file just for printed reports and the graphs there tend to be pretty simple: much like data-file graphs. A little easier for folks to take over the creation of their own reports if they don't have to wade through our interface graph. We may use a more strict anchor-buoy in these report graphs than in the UI graph (where our desire to have portability of layout objects sometimes has us linking all our anchor TOs together). (Did I just say that out loud?)

• IWP tends to want a slightly different interface (and in FM7 a slightly different graph) than FileMaker client.

• Portability. We tend to have modules like a calendar or navigation engine that get deployed in several projects, this kind of thing is somewhat easier to repurpose if it is its own file.

Love to hear others...