richard says:
I've never used attach either, though I too think it has something
good about it. Maybe one wants to be able to create a View object,
which specifies how to decorate a simple object. It would need
pairs of queries -- the first to specify where to attach things,
and the second what to attach. Then you could use a view on a single
tree display, or a keyset, and maybe dump via a view. In fact if
you ONLY dumped the parts that were specified, then you would have
your limited .ace dumper. Maybe there is a real idea here. Maybe
it could just be a file with pairs of queries.
but this is indeed how attach was created and used
we needed for the igd project (otto and myself) to do view dumps
so we created additional classes where all fields are derived via attachments
these classes are visible whereas the real ones are hidden
then you use acedb
the attach owrks then on objetcs, keystes and dumps
you can even parse what you dumped, but these fields are ignored
but then you make a second acedb with the same models as the views
but with direct fields and you read the dumps from the other system
now consider the server client model
the server can dump the (dynamically constructed) views as ace files
which are then read as direct ace files by the client
teh only missing link is thta only the super user can create these views since they are part of the modelsx file
now remember that i have a running version without clss/tags files where it is
necessary
to read a model file, so we now have the tools for what you need
from my experience of a couple of months, i think that attach is the most
powerful addition to the ace semantics since we introduced constructed types.
jean
