You can't call Internalize or Externalize directly. You can, however, call
ReadStore within Internalize, or WriteStore within Externalize. You don't
ever need to determine the type of the object: The Read/WriteStore
functions handle this automatically. If you are curious, you can do a
binary dump of a store file (using debug, od, etc.), and you will see a
heap of extra information in there including the textual name of the type
of the object. The framework uses metaprogramming to re-create objects of
the correct type.
>It is said that these procedures are used internally and are only
>EXTENSIBLE for backward compatiblity which may change in the future.
>On the other hand looking in the Form folder I found calls like
>r.Externalize^(wr), where a super call to the base method is done.
Super calls seem to have disappeared between 1.2 and 1.3. If you study an
example model/view implemtation (eg. ObxBlackBox, or a template generated
by the "Create Subsystem" tool), you will see that super calls are no
longer necessary in Internalize/Externalize. Perhaps they have forgotten to
remove a few of them. This is probably also a good place to see the
recursive calls to Read/WriteStore: A view is a store which contains
another store (its model).
>What's about domains? What do I have to do so that such a tree is
>stored and loaded again? Are there other papers to
>learn more about this problem?
Domains would seem to be an easier way of handling complex cyclic data.
>>>>
Stores may form arbitrary graphs. The "boundary" of a graph can be
determined by its domain.
This is an object which represents the whole collection of stores that can
be externalized to a file, or be internalized from a file. The stores of a
domain are externalized and internalized such that pointers among them are
reconstructed correctly upon internalization. In particular, alias pointers
are handled correctly: if several stores point to another element of the
same domain, this element is read in only once, and all the pointers to it
are rebuilt. Arbitrary graphs can be handled this way, e.g., cyclic data
structures. Links to stores of other domains are prohibited.
<<<<
Unfortunately, there doesn't seem to be any sample code explaining how this
is supposed to be done. It appears that Domains are usually associated with
documents, so you are usually only expected to propagate domains, not
create them explicitly. Although I haven't done it, my guess would be that
you need to:
1) Create a domain. If you were defining a model with a view, the model
would inherit the view's domain, which would in turn ultimately be
inherited from a document. If you just want to manipulate, store and
retreive (ie. not view) the structure you _ought_ to be able to create your
own domain that is not associated with a view. Models.NewDomain() appears
to be the only way to do this.
2) Assign the domain to each of your Store objects. You should implement
Stores.PropagateDomain for each type that you define. This should simply
call Stores.InitDomain on each of the stores that it points to (you can see
how to do this if you study a model/view implementation). Although not
stated, we have to assume that Init/Propagate domain handles cycles
correctly. You can probably call Stores.InitDomain to set the domain of
each object as you create it. Alternatively, you should be able to create
the entire structure and then call InitDomain on the root object (assuming
you have implemented PropagateDomain properly).
3) Use WriteStore on a root object to store the whole domain. Presumably,
your Externalize procedure should call WriteStore recursively to write each
pointer to a Store, and Internalize should call ReadStore to retrieve the
pointers.
I'm guessing at some of this, so I hope I haven't led you astray.
Domains are powerful, but not well documented. Some example code would be
very helpful here.
Hope this helps.
Regards,
Stewart