Is it worth it?

[grumbachr]

I just finished watching 2 videos from ISO FileMaker Magazine on "The separation Model" to try and get up to speed on how I can do this for a solution. In video 2 he got to a point were he was talking about mirror tables in the interface file (to show items in a portals). He described it as a record for record match of what is in your data file. Also how all data would have to be synced at startup? How would the data be synced if it were always open on FM Server or even just FM Client running as a server?

I really like the idea of having interface from data but this doesn't seem very logical to me. So I'm starting to question if this is right for me. Have others developed ways around syncing/duplicating records from one file to another?

Its also been asked what happens when you need to add a few data fields. I'm working on a "Canned" product and I know I'll eventually need to add fields.

This whole separation thing seems to have a lot more drawbacks right now than benefits.

What are others opinions?

[Genx]

I think you are misunderstanding the benefit - though i haven't watched the video.

The seperation model involves - in most cases - the seperation of your interface from your data. The backend (server side) holds your data and the front end stores your interface. This means 2 things - a ) you can have multiple GUI's running without cluttering your solution If your GUI is very large (mine is 14MB no data) you don't want this data floating back and forward over your network - graphics are large and kill your network resources very quickly. Effectively the GUI stores no data, and is simply a view into all of your data - your TO's that you see in the Define Relationships window are all simply windows into the backend data.

Soooo basically, depends on what your doing with your GUI - have a look in the seperation model forum for some more - i posted this exact same question when i started out - and though it's caused me some problems with accounts - it's will worth it so far.

[grumbachr]

I don't think I misunderstand the benefits. The benefits you mentioned are valid. Just from the videos it made me really question the value of the separation model.

I'm not going to have multiple UI at one time but I wanted to have one UI that could have incremental updates. Ideally the canned solution I sell could see some feature enhancements without having to have the person that purchased it export and import data.

I still feel like I'm missing something.

[harvest]

Just to throw in another 2 cents

I didn't watch the video either but I think, what makes it difficult is: there are two different approaches to separation. Model A has just data file(s) and GUI file(s) and in some cases separate printfiles while model B establishes a third layer in between data and GUI to hold the businesslogic. There are arguments for both solutions but I follow model A. From your description I suppose, the video shows model B where most of the calculations are dealt with in the businesslogic-layer. These hold the same tables and fields as the data-files and mirror the data to be worked on.

Model A works like a charme for me (and my customers). New functionality can be added by just switching the GUI file. Some developers favor adding fields in advance in existing tables to be used when needed if you can't get hands on the original data-files. Just give it a try, it's worth it. I would never go back to the old ways of FM <=6.

Holger

[Fenton]

I agree with Harvest. A Separation model does not have to be such a big deal. For example, I've not even built one yet myself. But I'm supporting a very large (huge) solution which has it (build by Nellie Korn, very solid). At first it was little intimidating. But I quickly got used to going to the Data file when necessary, otherwise everything's in the Interface file.

It was often necessary to also add fields, occasionally tables to the Data file. But quite a bit could be added to just the Interface file.

I found that I also had to add relationships for calculations to the Data file, for relational troubleshooting. But that was OK, as I often only added them to my copy; it was not necessary that the live files have them immediately; they were basically Developer fields.

I discovered that I liked this arrangement, esp. on very large solutions. It meant that the Data file had only "developer" layouts. So I could quickly see what I needed to, without wading through the many (>100) user, print, etc. layouts.

One area I found a little tricky is when you have a restricted privileges for people (such as no Export), and you run a script with Full Access, for something like Copy All Records. It doesn't really work, because the data is not in the Interface file, and the Full Access does not cross files. You have to either flip to the Data file (breaking your separation "purity"), and run the script there with Full Access, or use some other method, like a Loop. At least that's what I remember.

[grumbachr]

Thanks a lot for all the comments so far. I've decided to go ahead and build my solution using the seperation model based on all your feed back.

One question. In the typical seperation model does the UI file have many records itself or it it typically just One?

[Fenton]

Well, that depends what you use it for. But the simplest would probably just have 1 table, Globals (or Constants, or whatever), and probably just 1-record. The solution I was supporting had several tables, because it had an "abstracted" interface, where the tabs' names, many of the buttons, and actions, were created from reference tables in the Interface file. As I said, I didn't write it; I can barely understand it -]

[harvest]

One table should be enough as fenton wrote. I keep one with globally stored Fields. Half of it are filled with information collected on login (login-date, users name, privileges...), the rest is used for dataselection etc.

I have established a second table for fileinfo where I track development information as version, developers name, change-history... but that's not really needed

Holger

[grumbachr]

I guess I'm just not getting this quite yet. I thought I had a good understanding but now after starting to build my own solution I'm just confusing myself even more.

I got all my data in one file and that seem like the easy part. However, in my UI file I'm having to create a new record each time I want to add a new one to the data file.

I also feel like I'm going to need a lot more than one table in my UI file.

sorry just venting some frustration...

[Genx]

I have to admit, i do not have one field in my front end - never really had the need.

[Genx]

I'm having to create a new record each time I want to add a new one

...

[Fenton]

grumbachr, just put table occurrences (TO) from the tables of Data file into the Relationship Graph of the Interface file. Create layouts based on those TOs. Then create scripts based on those two. Really, it's almost the same as working within the Data file. The one rather large difference is that you have to back to the Data file when you need to do anything with fields themselves.

Here is a 5 min. example.

Separation_fej.zip

[grumbachr]

Thanks a million for the example.

I think my biggest problem right now is that I'm thinking to hard about it. One minute I think I've got it the next I'm not sure.

[Fenton]

Yes, a file is worth a thousand words. It's hard to see how easy the basics are until you see it (duh). The idea of putting one file's table occurrences on another file's Relationship Graph is something we do all the time (if you've ever contverted a solution from 6). The idea of putting some layouts based on those TOs in that foreign file is also something we do a little, for convenience. The idea of doing everything in the Interface file is just an extreme extension of those ideas.

FileMaker 7/8 is much less concerned with what actual file it is (once the other file is in its File References); it's more concerned about what table occurrence.

You should experiment. You'll see what you can do exclusively in the Interface file (quite a bit). And what you can't. The latter will include calculations, including relational calculations. So you'll need a few TOs for this in the Data file also. If the relational calculations need to evaluate in different table occurrence groups (TOGs) than the main one for that table, be sure to specify the correct one for it to evaluate on (at the top).

Set it up. Build what you need to get some things working. Then see if you can replace the Interface file with a new one. If something you need got left behind in the previous one, then you know you need to rethink that part.

A table you might want to add to the Interface table is one for temporary globals; mostly for ones you might need to use in a relationship. You don't really need globals just to pass data anymore; you can use Script Parameters and Script Variables.*

*There is a very clever technique (someone else came up with) to set named Variables to Script Parameters, using the Let() function within the Script Parameter dialog.

About defining variables in script parameters. Remember that you can put a calculation into a script parameter. And you can use the Let function to define variables in that script parameter.

This is very cool, people. This is the syntax direct from a working example:

Let ( [$$_no_dialog = 0; $$_Report = “Tasks”; $$_Detail=“Itemized”;$$_Start=“Proposals”] ; “” )

Notice that the result calculation is just quotes around nothing. All this does is define script variables. This takes the place of either being limited to a single script parameter or creating a combo script parameter with pipes or some other divider between parameters and then having to parse it out later.

I'll just add that it also names them, so you don't have to guess what Parameter[3] is later; though you do have to remember your variable names (which is one advantage of global fields, they're named; one can use various methods). I see you have Advanced. Use the Data Viewer to check your Variables.

Edited July 17, 2006 by Guest

[greg@work]

Yipee - Having just got FM8.5Adv and being a past 5.5Dev user thanks for the example, was not sure myself how easy this was to seperate the GUI and data but hey easy as pie

Anyone else got some good larger examples just for reference purposes that show (model A) file seperation :)

[nick_jp]

Can someone please make this thread - or at least Fenton's dummy file - a sticky? I spent HOURS sifting through books and sites trying to find out how that works.

[Lee Smith]

You can make a topic a favorite, and then review it when ever you like by reviewing your "favorite" topics.

Click on the button below labeled [color:red]Add to Favorite Topics

HTH

Lee

[nick_jp]

Not for me - I know how to do it now. But the dummy file answers every "hey, what do I click to get this separation model going?" question until the end of time.

[DataMate]

I have developed a rapid deployment data separated framework if you want a copy. The framework for data separation is very useful for many things, more so than not in my opinion. I don't understand where the sync thing and replicating stuff gets in there... It's not necessary with the right set up