FileMaker Pro's User Interface Discussion

[Tyson]

Im not sure if anyone is aware, but did u know there is a way to create a user interface for your solution. With this type of user interface you never have to import records. I have my interface with absolutly No Tables------ Just Layouts And scripts. If anyone is interested let me know I could probably Post an Example. Let me know if anyone else is doing this. I would like to know if there are any problems with doing it that way vs just coding 1 file instead of 2. Let me know.

 

-Tyson

[Tyson]

Ok here is the example there were a few people interested. take a look at the interface file. Look at the tables and look at the relationships. Tell me what u think.

 

-Tyson

[Ted S]

It's called the separation model. There's been a lot of discussion about it on other FileMaker boards.

 

I'm working on a small application that I'm going to try to separate but as you get farther into it you will realize that it will be difficult to get 100% separation.

[CobaltSky]

Hi Tyson,

With FileMaker 7, efforts at 'separation' of data and interface make a lot more sense (and require rather less work) than was the case with earlier versions for FileMaker. But nevertheless, the architectural model of FileMaker is still designed for convenience and integration first and logical 'design purity' second. So as Ted has remarked, 100% separation is not really an option. For example you will almost certainly require some calculations within the 'back end' file - possibly including some whicch are primarily for interface purposes - and those in turn will likely necessitate some relationships in the back end file.

 

As soon as you have any calcs or relationships in the data file, the separation is no longer 'pure' and you run the risk of having to update the back end file for any significant change in functionality.

[ QUOTE ]

With this type of user interface you never have to import records.

 

[/ QUOTE ]Well, *never* is a big word. Even leaving aside the question of calcs, relationships, validations etc in the back end file, any change which requires an adjustment of the data model will require an update to the back end. So although with careful design you may reduce the need for import-based update procedures, with all that that entails, you're unlikely to avoid it entirely.

[Tyson]

Ok so in other words should i avoid this or should I Implement this??? Im still not sure on what i should use. I do know of a company localy that uses the seperation method. According to them the have back end calculations yes, but they still do not have to import any data for updating. Still dont know what i should choose ?????

[Ted S]

Tyson,

 

I think the answer to your question is "it depends." I personally hate answers like this yet I just gave you one. Here's my thoughts:

 

I work full time at a company that runs FM to fill in the gaps where the core information system comes up short. Since I'm there 40hrs + per week and can VPN in from home I have essentially continuous access to the system. Given this fact I'm doing everything in 1 file - I'm not using the separation model because I can jump on at anytime and do anything.

 

I'm also doing some moonlighting for a much smaller company that is not connected to my day job at all. I normally will have no direct access to their system. If I need to add a new feature or correct a problem I may have to drive over and replace a file or talk them through it. I'm going to try the separation model for them because export / import seems like a lot of work. I'm still working on it so I can't give you any advice based on experience.

 

That's my thoughts. I'm curious as to others opinions.

[Tyson]

Hey Thanks for the opinion Ted. I kinda feel like its almost another step just to seperate. I mean within the future to come i think that all businesses will have VPN setups and what not so why seperate and go back to the multiple file like fm6. I hated that in 6 now everything is locally processed on one file. Also i noticed in 6 that when relating large data through relationships it tended to slow down the database i dont know if that is still true or not, but i think that im not going to go with the seperation model. Any opinions would be great!!

 

-Tyson

[jonmeyer]

I think the argument over separation of data and interface is interesting. I have considered separation before, but opted against. Mainly due to a couple of reasons: 1) My clients are usually not too far away for the odd visit to handle updates/imports etc.. 2) Updates are generally infrequent. 3) Invariably changes to the interface will have a knock on effect on the data input and vice versa. Therefore one often has to do both anyway, and so I find it more convenient to access everything in the one file.

 

Just a note on the TO graph - to keep it less complex in larger solutions I group the TO in rows down the left and show related TOs to their right in a kind of horizontal family tree. I also use the add/edit table buttons rather than drag the fields from one TO to the other - I find less room for confusion that way. Colour coding also helps. Interested to know how others feel