World: r3wp

ahh ... well problem solved :)

seems not :(

>> pharmacy: make object! [
[     name: none
[     init: func [ n ][
[          self/name: n
[         ]
[    ]
>> a: load mold/all make pharmacy []
>> probe a
make object! [
    name: none
    init: func [n][
        self/name: n
    ]
]
>> a/init "testing"
** Script Error: self has no value
** Where: init
** Near: self/name: n

if you have a function inside, I think you have to do it instead 
of load it.

functions cannot be serialized... so they have to be bound somehow.

Why not remove the self ? [not a metaphysical question in this context]
    ph: make object! [
        name: none
        init: func [n][
            name: n
        ]
    ]

seems functions can be serialized, but I don't understand why the 
self isn't being bound to the object..that is strange.

because it won't work?

ok, to use do, you must forget the /all.


so the above, minus the /all should work with self... (it does in 
my tests)

It worked for me, when i tried it.

so, I have to  now do

a: do load mold make pharmacy [ ]  ?

a: do mold pharmacy [ ]

a: do mold pharmacy ;

yes since I removed the make.

This solution seems a little tortued :)

not really, the way I see it is that we are taking advantage of rebol's 
features.

Do has some dangers if you do not trust the code involved. This works 
for me, and keeps the load/all (but not the self).....Even more tortured:
   a: first reduce load/all mold pharmacy

but note that your object's structure has to remain pretty static 
for any type of deep copy like this to be usefull.

what do you mean?

talking to who?

deep copy

what do you nean by structure has to remain pretty static?

well if the pharmacy object can have 1 or 5 addresses, some people 
3 different ways to refer to patients, etc... then the copy still 
has to be meddled with.

if the db returns lists of varying length and types... you're better 
off creating a structured approach to a recursive initialisation.

I'll be creating an empty object and then populating it once created

ok.

You may have some other issues to consider as part of building/loading 
the data structures.

For example, Version2 of the application adds some fields  not present 
in V1.

To avoid a one-off bulk conversion exercise, the load process needs 
to check each object and add missing fields with default values.

I'll just change the object templates

What I need to do is to create the object, create the xml from the 
object, and then submit it via ssl to the gateway server

and then I can discard it ...

That makes life a bit simpler.....Objects with year-long lifespans 
can be harder to manage :)

I have configs that are saved in the db as objects ... and those 
i have to check each time :(

And when my app crashes as it does often enough, I save state as 
an object .. and that has to be checked as well when reloaded.

We have similar issues at REBOL.org where just about everything [scripts, 
Ml posts, internal data structures, etc] is objects, or blocks of 
objects.

Data sanitisation and object upgrading is a major part of the gig.

Interesting...

and these are stored where? In the filing system?

I'm pretty sure rebol.org doesn't use a db backend.

[we're off topic for XML -- please continue in Library if you want 
more details]. Stored in text files and binary files (which are generally 
just compressed text files. No database!

Functions can be serialized, but the only word contexts that get 
restored are the global and thee function local context. Any intermediate 
contexts, like object contexts, don't get restored.

That's because the "intermediate" contexts don't really indermediate 
- they get applied in order by DO.

indermediate -> intermediate

In case, it's needed, RebXML spec:
http://www.fys.ku.dk/~niclasen/rebxml/rebxml-spec.html

has anyone got a working copy of parse-xml.r from the library?

Don't remember if I tried parse-xml.
I do use xml-object wich works well for me:
http://www.rebol.org/view-script.r?script=xml-object.r

that's the complementary script ...

Both parse XML. The main difference is:
-- xml-object.r uses REBOL's built-in mezzanine, parse-xml
-- parse-xml.r is an improvement for parse-xml

In theory, you could use both together.

In my experience, xml-object.r is all I need to parse XML .....  
the XML I encounter just does not need the extra oomph supplied by 
parse-xml.r

Got a working example of their use?

I keep getting errors

This works for me:
    do %xml-object.r
     xml-file: read %my-xml-file.xml
     xml-object: first reduce xml-to-object parse-xml xml-file

Though the resulting object does need some tidying up

Hmm.  There is no 'xml-object function

oh ...sorry