World: r3wp

well, output is first, reading is the next task :)

it's all in a DB.

this is part of the xsd .. found an example http://stackoverflow.com/questions/790118/jaxb-types-problem

what I can suggest is that you build your objects like so:

xml-attribute: context [
	name: "someattr"
	value: "somevalue"
]

xml-tag: context [
	name: "FileID"
	content: []  ; a block of inner xml-tag objects
	attributes: [] ; a block of xml-attribute names
]



then all you do is nest objects in objects, filling them up item 
by item recursively using DB data.

the downside is that access either needs a wrapper func, or is done 
via indexes...


actually attributes could be an object, since their names are mutually 
exclusive within an element.

Let me understand this .. if I have an object that needs other objects 
more than 1 deep .. I can't use that to clone other objects without 
creating references instead of copies.

you can just do a mold/all load, that will in effect copy the whole 
tree along with all the series too.

I was just thinking that.

ex:

load mold/all make object! [
    a: make object! [
        b: make object! [
            c: "tadam!"
        ]
    ]
]


will effectively create a complete duplicate of the whole object 
tree.

but remember to use mold/ALL  cause otherwise you end up with gibberish...

So, I can continue to make the objects as I have been doing.  But 
just before I use it ... I load mold/all on it to ensure I have unique 
objects

ie. I load a serialized form of the object

yes.

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!