I'm going to rebuild a solution that was originally built in FM6 to a FM7 solution. I really like the idea about the separation model. Mostly because of the ease of updates. I'm distributing the same solution to several different customers, and when something needs to be done, it needs to be done so many times.

I'm kind of new to the separation thinking, but I have a structural question.

Is it a good idea to have a separate "interface" layer? I mean, with no scripts (or as few as possible) and of course no data. The idea is to be able to make customer specific changes to layouts etc, which is not affected by an update of the "buissness" layer.

Do you get the idea?

Any pros and cons?

Thanks

/Johan

That's an interesting concept. Years ago I was writing software that was distributed in other countries by different companies, so I not only needed local branding, but language screens.

Fortunately before completing the project, I saw a Macintosh and how they handle what they call their 'resource fork', and that concept paved the way for my solution for IBM software.

Your idea is similar in many regards, and by establishing a separate file of localized layouts, you're obviating the need to tinker with files that contain live data.

Yes, I like your idea.

Normally the interface file has no tables and thus no fields. But it does have layouts, relationships, valuelists and scripts. If you use a 3 file model the data file has only data, no calculations and few if any relationships & scripts. The Business Rules & Report file has calculation and summary fields, and relationships necessary for reports & calculations.

[color:"purple"]Normally the interface file has no tables and thus no fields.

If the view layer needs a table, give it one.

[color:"purple"]Normally the interface file has no tables and thus no fields.

If the view layer needs a table, give it one.

[color:"purple"]Normally the interface file has no tables and thus no fields.

If the view layer needs a table, give it one.