Interface and tables

[rivet]

With the new FMP7, can anyone see a way to keep tables and interface seperate? The challenge with FMP has always been upgrading a solution.

[Ocean West]

There is a file I attached to this post you can look at it and think of the possibilities...

http://www.fmforums.com/threads/showflat.php/Cat/0/Number/96260/page/0/view/expanded/sb/5/o/all/fpart/

here is a direct link to the file

http://www.fmforums.com/threads/download.php?Number=96260

[LeCates]

Hi rivet,

You can reference tables from external files. As such, it's possible to include external tables on the Relationship Graph, and then build layouts and scripts upon those external tables.

So, yes. You can separate Layouts and Scripts from data tables completely. Since they form the bulk of your interface development, FileMaker 7 certainly allows for much more elegant separation of data from interface than in prior versions.

However, calculation fields must be defined with the data tables, although they too rely on the Relationship Graph. So you cannot separate calculations from the data tables. As calculations fields are also a significant participant in interface development, separation of data and interface in not complete in FileMaker 7.

Note for the record, that fewer calculation fields will likely be necessary for driving the interface (than in prior versions), though some forms of calc field driven interface will persist and be critical. Finally, there are a number of advanced techniques being explored that may allow near total separation of data and interface. They wont be universally relevant to all developers, but options may become more clear with time.

Cheers,

Andrew

[Mariano Peterson]

Yes, the improved potential for separation is nice.

However, performance seems to be much slower when working with file references. I created a layout in File 1, based on a table from File 2. When I clicked quickly from one row to the next, it took the screen several seconds to catch up with my clicking. Basically, I clicked on say 15 different rows, then took my hands off the keyboard/mouse and watched for several seconds as the cursor slowly moved from record to record, trying to catch up to my actions.

When clicking through the rows in a layout that pulls data from a table in the current file (no file reference), the performance seemed to be OK.

The layout in File 1 used a table view, and only displayed one field from File 2 - a simple text field. File 2 only had 23 records total, so the file was very light weight.

With that sort of performance, I can't imagine implementing a seperated model with out a severe backlash from the users who have to deal with the decrease in performance.

[LeCates]

Hi Mariano,

The experience you relate shouldn't be the case. I have a six-table solution in front of me that I built twice. Once with all tables in one file & once with all tables externally referenced in their own files. Both solutions are exactly the same in all ways, except for the tables being internal v. external.

There is no speed degradation in the multi-file solution when moving between records in a table view with 5,000 records (record count really shouldn't matter anyway in record to record navigation).

Are your externally referenced files from a different volume, or is your File 2 in the same directory with File 1? (trying to eliminate obvious variables). Would you mind sharing more details on the config and solution?

Net net: This response is not meant to say 'your wrong!'. Only that there _should_ be no material difference in performance between external and internal tables - assuming all else is equal.

Cheers,

Andrew

[Mariano Peterson]

I've uploaded the files I described earlier. There are two files:

Issue Tracking.fp7 => I created this using the FileMaker templates.

Issue UI.fp7 => I created this from scratch. It doesn't contain any tables. It has one layout which displays data from a table in Issue Tracking. This layout is very slow when viewed as a table or list (as opposed to a form).

---

I suspect this slow down is similar in nature to the slow down I experience when moving objects around in layout mode. As I've mentioned in other posts, it feels like I'm wading through molasses. It takes several seconds for the screen to catch up with the mouse movements. This happens on both my home computer and my work computer. I have a feeling this has something to do with my high resolution (Win 2K Pro, P4 1.7 mhz, 512MB, Radeon 32MB video, 2560x1024; Win XP Pro, P4 1.7 mhz, 512MB, NVidia 32MB video, 1600x1200).

However, FM7 is the only application on which I have experienced any display problems at all. No other application I work with behaves in that manner, including FM6.

The slowness experienced in Layout mode makes FM7 an workable product for me. I simply cannot develop FileMaker applications at a remotely decent pace with this handicap.

fm7_ref_table_slowness.zip

[Mariano Peterson]

Sorry I forgot to attach the file to the previous post. Its there now if you want to have a look.

[Mariano Peterson]

So has anybody else experienced this? Is this just a problem with high resolution displays? Are there plans to fix this?

[-Queue-]

Working on 19.1 inch LCD flatscreen set at 1280 x 1024 produces no problems. My RAM is 1 GB and speed is 3.0 GHz, however, and graphics card is 256MB, though I don't see why it should be an issue.

[belgiumbruno]

Hi,

I converted an fm 6.0 application to fm 7 and experienced the same problem.

I have a tabbed interface and when I click a button to go to another file

it takes minutes.

I also saw that with the conversion, a lot of filepaths were wrong

BelgiumBruno

Version: v7.x

Platform: Windows XP

[Steven H. Blackwell]

File references should most likely be cleaned and consolidated BEFORE converting your files.

Use MetaDataMAgic's FIle Reference Fixer:

http:///www.newmillennium.com

Steven

[mscholtz]

LeCates said:

...

So, yes. You can separate Layouts and Scripts from data tables completely. Since they form the bulk of your interface development, FileMaker 7 certainly allows for much more elegant separation of data from interface than in prior versions.

However, calculation fields must be defined with the data tables, although they too rely on the Relationship Graph. So you cannot separate calculations from the data tables. As calculations fields are also a significant participant in interface development, separation of data and interface in not complete in FileMaker 7.

One thought: I did notice (at least I think I did) that you can now define global calcs. Meaning not only that they operate on globals (you could always do that) but that the result is a global as well.

So I'm wondering: if the calc you need is just for the purposes of display in the GUI when viewing a record, maybe you could (as part of your scripted record navigation) load the relevant fields into a global table in your front-end file, then run the necessary calcs as global calcs.

This of course wouldn't take care of every instance in which you would need a calc, but I'm wondering if it's one place where you might be able to avoid having to make changes to your back-end while making changes to your UI.

Matthew

Version: v7.x

Platform: Windows XP