TOG and Spaghetti

[Himitsu]

I got a weird thing here... I need some clarification here. I have a kind of complicated system I am doing for a client and it is live but now they want a lot of different layouts for each position of their workers. That sounds fine but each different layer will show data from other tables from different keys. Already the base occurrence is getting a lot strings flowing from it. I want to move to different TOG for organizing purposes but a lot of scripts and portals rely on that relationship from the main occurrence. How would I create a new TOG without having to duplicate all those scripts and goTo items?

[David McQueen]

I got a weird thing here... I need some clarification here. I have a kind of complicated system I am doing for a client and it is live but now they want a lot of different layouts for each position of their workers. That sounds fine but each different layer will show data from other tables from different keys. Already the base occurrence is getting a lot strings flowing from it. I want to move to different TOG for organizing purposes but a lot of scripts and portals rely on that relationship from the main occurrence. How would I create a new TOG without having to duplicate all those scripts and goTo items?

Take a look at the Anchor and Buoy concept for organizing relationships.

1. When in any layout, that particular layout will belong to one of the tables in the solution. All table occurrences to other tables that can be seen from that main table should be connected to that particular table occurrence. In other words, make one window (table occurrence) from each table to view other tables. These primary occurrences are not connected to each other.

2. This leads to specifying a main table occurrence for each table and associating all layouts belonging to that table to that particular occurrence of the table.

3. All other table occurrences of that table are used to look at the contents of that table from some other primary table occurrence connected to some other table.

4. The structure that results in your relationship graph is often described as a series of "squids" - a head table occurrence (say to the left)and a series of trailing table occurrences representing tables that can be viewed and manipulated from the original table to the right.

5. Each "squid" is independent of every other squid. You use layout navigation to determine which views are possible in any part of the program.

The result of using this structure is that relational interdendencies are minimized so that you can make changes to one part of the system without throwing out other parts.

Hopefully I have been clear. It is much harder to describe that use once you are into it. It will save you much grief later.

HTH

Dave

[Himitsu]

I know somewhat about it and most of my designs are like that but this one I'm working on has so many portals and value lists that are specific to the current TO that it's getting ridiculous. I guess I'm just trying to limit the occurrences and script steps thinking it will save me time but the more dynamic functionality this customer is asking for as the project progresses, it's starting to get crazy. And now if I back up and go with a clean buoy layout, I might as well start over. Don't you just love how the customer changes directions from the original design!?

I know someone is going to post saying it's me... And they're right.... The thought that "well they'll just add this one more VL and be done" so I don't need to start a whole new TOG for that, is wrong!