Hi,

Sorry this is long, and possibly a little (lot) abstract too.

Say you are using functional groups to define relationship trees (aka
FTOG design or "Functional Table-Occurence-Group design") and you need
to transfer the 'found set' from one tree to another. e.g. you have
two TO's based on the same table, but in different groups.

I already know you can transfer the found set via the GTRR script
step, if you set it up appropriately. No problem there. Well, at least
not for -this- post.

My question / request for comment is on where one should ideally PUT
that script step, from a designers standpoint.

For example, if I'm writing a script in one TOG (call it TOGA) and its
going to call a function in another TOG (call it TOGB) and it wants
the target function to operate on the current found set I need to
transfer the found set from TOGA to TOGB before the TOGB script
executes.

Now there are several ways of doing this:

1) I can GTRR from the calling script, immediately prior to calling
the script in the other TOG
2) I can GTRR in the called script, as its first action
3) I can put the GTRR in a separate script, creating an interface
layer.
4) Other?

Pros and Cons

1) From the calling script
Pros:
Its simple.

Cons:
The calling script is part of references the an external TOG layout
directly. This is bad because it violates modularity. Ideally, the
implementation details of TOGB are completely private. TOGA shouldn't
know about them or reference them. If I delete the TOGB layout, I'll
break TOGA, that's bad. Ideally, the only part of a TOG I should have
to worry about changing are the function signatures that are
'public' (ie that are marked as being callable by other TOGs)

Its a very big con, in terms of the maintainability of the solution.

2) From the called script
Pros:
Its just as simple

Cons:
Same as above, moving the GTRR into the called script puts a reference
to an element of TOGA in TOGB, and making changes to TOGA down the
road could break TOGB.

Its also less flexible than 1) above, because now the called script
ONLY can be called from TOGA. If I want to to transfer a found set
from TOGC and call the script I have to create another script.

3) Interface Layer

In this solution, I create a script called
Interface_TOGA_TOGB_TransferFoundSetoF_ZZZ
with a single GTRR script step.

Now, the TOGA calling script calls the above script, prior to calling
the TOGB script.
The idea is that the Interface script allows TOGA and TOGB to remain
properly isolated. If I make changes to either TOGA or TOGB I'll have
to review all the 'interface' scripts as well. Its a hassle, but it
beats the heck out of having to inspect the entire solution.

Pros:
It almost preserves modularity, by isolating the modularity
'violations'.

Cons:
script proliferation
it doesn't really preserve modularity, it just helps isolate issues to
make them easier to find

4) Other
Not really sure what else we could do. One option is to designate
certain layouts as 'TOG found set transfer destinations'. The point
would be to effectively expand the public signature, by designating
one of the TOG layouts as 'public'. Meaning that like 'public' script
signatures you would know that making changes to it is fairly risky,
as it might be referenced anywhere in the solution.

The pro would be that you could use option 1) above to do the GTRR. As
the referenced layout was specifically marked safe to reference
externally.

The con of course is that by exposing layouts you crack the
encapsulation/modularity wide open. further restricting your ability
to easily modify the TOG. Plus you have a whole new domain to worry
about. Previously your TOG 'interface' was limited to scriptmaker, now
its expanded to layouts.

I'm not really satisfied by any of those ideas.
Are there any other/better approaches to this??
What do you do?

-regards,
Dave