The schemes I have in mind, and have used in the past to compile resume
data, is actually very very rudimentary. Basically, you would take the form
struct as it comes in, wddx it, and store it in a repository for later
compilation! If you need to edit it, just grab the info from the db, un
wddx it, and it's back into the form struct again.
All you have to do it plop it back into the original form for editing.
Very simple, and amazingly robust, even if you add or remove elements from
the forms that produced them. The only complex part of the scheme is
indexing the stored forms so that you know who owns the data, from which
application/page of the builder it originated, etc. But, once you get the
hashing algorithm in place, it's a piece of cake.
This schema is not inherently compatible or incompatible with the user
records already in place, since all it's doing is store forms of
information, which can then be compiled into working resumes or stored in
some other tables. The benefit in this case would be *rapid* development of
the user interface and step through process of building complex resumes...
even if the process is 20 steps with multiple iterations of any of the
steps.
But, I'm rambling... time to go back to work!
-joshua
----- Original Message -----
From: "Michele Foster" <michele at wordpro.on.ca>
Subject: Re: [thesite] Members' Directory/Pages
> Joshua,
><snip>
> Do you have any database schemes we can look at? Actually, for Rudy and
> Erik to look at and compare the existing members schema and then we can
> decide what additional fields/information we need to add.
>> I'll let Rudy pipe up here and explain the evolt database.
>> Michele