SeedCodeComplete3

Separation Model

SeedCodeComplete3.SeparationModel History

Hide minor edits - Show changes to output

May 04, 2015, at 10:06 PM by 142.4.217.187 -
Changed line 10 from:
That is the goal, at any rate. Substantive new features may, of course, require changes to both the interface file and the data file. But separation does offer a good way to speed development of new changes once a solution is up and running. And if you do need to load up a new version of the data file, our [[updating | "update"]] scripts can help move the live data into your new data file.
to:
That is the goal, at any rate. Substantive new features may, of course, require changes to both the interface file and the data file. But separation does offer a good way to speed development of new changes once a solution is up and running. And if you do need to load up a new version of the data file, our "update" scripts can help move the live data into your new data file.
December 08, 2014, at 02:59 AM by 71.229.202.172 -
Changed line 3 from:
"Separation" is a technique to isolate the data in a FileMaker solution from the scripts and interface. This is done by using separate files (separate .fmp12s) for the interface and for the data. And in the case of SeedCode Complete, we have further separated the data into two files: SeedCodeModel.fp7 and SeedCodeMedia.fp7-- this is done because the media file can get quite large over time and with them separated this way you can, for example:
to:
"Separation" is a technique to isolate the data in a FileMaker solution from the scripts and interface. This is done by using separate files (separate .fmp12s) for the interface and for the data. And in the case of SeedCode Complete, we have further separated the data into two files: SeedCodeModel.fmp12 and SeedCodeMedia.fmp12-- this is done because the media file can get quite large over time and with them separated this way you can, for example:
December 08, 2014, at 02:58 AM by 71.229.202.172 -
Changed lines 3-4 from:
"Separation" is a technique to isolate the data in a FileMaker solution from the scripts and interface. This is done by using separate files (separate .fp7s) for the interface and for the data. And in the case of SeedCode Complete, we have further separated the data into two files: SeedCodeData.fp7 and SeedCodeMedia.fp7-- this is done because the media file can get quite large over time and with them separated this way you can, for example:
to:
"Separation" is a technique to isolate the data in a FileMaker solution from the scripts and interface. This is done by using separate files (separate .fmp12s) for the interface and for the data. And in the case of SeedCode Complete, we have further separated the data into two files: SeedCodeModel.fp7 and SeedCodeMedia.fp7-- this is done because the media file can get quite large over time and with them separated this way you can, for example:
Changed lines 6-7 from:
-> Email the interface and data files to your developer without having to send a possinbly huge media file.
to:
-> Email the interface and data files to your developer without having to send a possibly huge media file.
Changed line 22 from:
-> Renaming files can break the links between them: remember, the interface file is looking for a data file named "SeedCodeData.fp7" so follow our instructions for [[renaming files]] if you'd like to change the names.
to:
-> Renaming files can break the links between them: remember, the interface file is looking for a data file named "SeedCodeModel.fmp12" so follow our instructions for [[renaming files]] if you'd like to change the names.
Changed lines 10-11 from:
That is the goal, at any rate. Substantive new features may, of course, require changes to both the interface file and the data file. But separation does offer a good way to speed development of new changes once a solution is up and running. And if you do need to load up a new version of the data file, our data migration scripts can help move the live data into your new data file.
to:
That is the goal, at any rate. Substantive new features may, of course, require changes to both the interface file and the data file. But separation does offer a good way to speed development of new changes once a solution is up and running. And if you do need to load up a new version of the data file, our [[updating | "update"]] scripts can help move the live data into your new data file.
Changed lines 10-11 from:
That is the goal, at any rate. Substantive new features may, of course, require changes to both the interface file and the data file. But separation does offer a good way to speed development of new changes once a solution is up and running.
to:
That is the goal, at any rate. Substantive new features may, of course, require changes to both the interface file and the data file. But separation does offer a good way to speed development of new changes once a solution is up and running. And if you do need to load up a new version of the data file, our data migration scripts can help move the live data into your new data file.
July 14, 2010, at 06:33 PM by 76.22.123.157 -
Added lines 18-19:
-> When you're defining fields, you have to do this in the data files. This can be kind of weird at first, since you enter define fields on then contacts layout and the contacts table isn't there: it's in the data file, you'll get used to it. When FileMaker is open your data file will be listed in FileMaker's "Window" menu, possibly under the "Show Window' submenu.
Deleted lines 21-22:
-> When you're defining fields, you have to do this in the data files. This can be kind of weird at first, since you enter define fields on then contacts layout and the contacts table isn't there: it's in the data file, you'll get used to it.
July 14, 2010, at 06:13 PM by 76.22.123.157 -
Changed lines 14-15 from:
!! Caveats
to:
!! Things to keep in mind.
Deleted lines 24-28:




That's it.
July 14, 2010, at 06:13 PM by 76.22.123.157 -
Changed lines 22-24 from:


to:
-> Renaming files can break the links between them: remember, the interface file is looking for a data file named "SeedCodeData.fp7" so follow our instructions for [[renaming files]] if you'd like to change the names.

-> The interface file ''needs'' the data file. So if you take a copy offline to work on it, you'll want to take both the interface file and the data file. It's also a good idea to turn sharing OFF on your local copy of FileMaker when you're developing on an offline copy- you won't want your users to accidentally open your offline copies instead of the official served versions. To keep everything straight we recommend [[renaming files | renaming]] your offline files: this will prevent you from getting confused as well.



July 14, 2010, at 06:06 PM by 76.22.123.157 -
Changed lines 1-8 from:
!! Do I need to do anything different when pasting the calendar into a separated system?

Not really--
the graph show in our [[integration]] article should be in your Interface file just as it is shown in that article. All the layouts mentioned there should be in your interface file as well.

The SampleEvents table there can be in another file (your data
file, presumably).

There is one calc in SampleEvents that needs to know about the CalendarRows table: the optional calc you may want to use if you wish to show events colors "on" the event record in list view or in the Event Details mini window. So you'll want to add a table occurrence for CalendarRows to your data table so the calc "z_sc_ColorCalc"
can evaluate properly.
to:
!! How does separation work?

"Separation" is a technique to isolate
the data in a FileMaker solution from the scripts and interface. This is done by using separate files (separate .fp7s) for the interface and for the data. And in the case of SeedCode Complete, we have further separated the data into two files: SeedCodeData.fp7 and SeedCodeMedia.fp7-- this is done because the media file can get quite large over time and with them separated this way you can, for example:

-> Backup the media and the data files on different schedules.
-> Email the interface and data files to your developer without having to send a possinbly huge media file.

But the real benefit of separation is that is makes it easier to make changes to your solution. This
can be overstated, but in general, you may be able to take the interface file offline, make changes to it, and the redeploy it while your users continue to use your data file. Furthermore, you can likely send a copy of your interface and data files to your developer so that he or she can write some new scripts for you, and the developer could return a new interface file that you can deploy '''without having to import all your data back into the solution'''.

That is the goal, at any rate. Substantive new features may, of course, require changes to both the interface file and the data file. But separation does offer a good way to speed development of new changes once a solution is up and running.

Check out %newwin%  [[http://sixfriedrice.com/wp/an-overview-of-the-six-fried-rice-methodology/ | SRF's description of separation]] for a nice overview of these same ideas.

!! Caveats

So there are a few things to be aware of in a separated, or multi-file solution:

-> All files in the solution need to share the same account names and passwords. If you have a ton of users and this becomes unwieldy, consider using %newwin% [[http://www.filemaker.com/downloads/pdf/techbrief_fm8_server_auth.pdf | External Authentication]]: it's a perfect solution.

-> When you're defining fields, you have to do this in the data files. This can be kind of weird at first, since you enter define fields on then contacts layout and the contacts table isn't there: it's in the data file, you'll get used to it.



February 21, 2010, at 02:36 AM by 76.22.123.157 -
Added lines 1-9:
!! Do I need to do anything different when pasting the calendar into a separated system?

Not really-- the graph show in our [[integration]] article should be in your Interface file just as it is shown in that article. All the layouts mentioned there should be in your interface file as well.

The SampleEvents table there can be in another file (your data file, presumably).

There is one calc in SampleEvents that needs to know about the CalendarRows table: the optional calc you may want to use if you wish to show events colors "on" the event record in list view or in the Event Details mini window. So you'll want to add a table occurrence for CalendarRows to your data table so the calc "z_sc_ColorCalc" can evaluate properly.

That's it.
(855) SEEDCODE
[email protected]
Follow us: