Tim Cook schreef: > Hi Bert, > > [this thread may belong on the implementers list?] > > On Wed, 2008-04-23 at 14:43 +0200, Bert Verhees wrote: > > >> I have my system ready in a way that it eats archetypes, and data >> belonging to those archetypes, and stores them in over a persistence layer. >> > > >> There is only one important step, that is, what is a good way to connect >> the data to the archetypes. Is this dADL, or better XML, or other means. >> > > I'm not sure I understand you correctly. But are you saying that you are > storing an empty archetype in a repository and then in other tables > (assuming a SQL database) storing the data collected from a GUI or > webform that was based on the RM constraints represented by that > archetype? > No, no, the persistence part is ready. No problem. Archetypes are in fact RM-objects, I have a way to store RM-objects efficiently.
My problems is that I am looking for an elegant and efficient way tot connect data to an archetype. A way that can (will) be machine-generated It is indeed possible that an archetype/template-engine will generate a HTML-form. The data in that form must be handed over to the kernel. This is the spot where I am thinking about. Because my kernel on forehand does not know which archetypes it will have to "eat", it eats every archetype (if not it is a bug to be fixed) Now, the data must come with the archetype , the kernel needs to eat all data that come with a valid archetype. My question: In what form should I shape the data, so that form is usable with every possible valid archetype? Is the answer dADL, or do I miss the purpose of dADL? Or am I thinking of a misuse of dADL. I have given my self a few days to think about this. so there is no hurry? Maybe I ask the wrong question and should think about this in a compleet other way. ----------------- Let me tell you what I have. I have wonderful code from Rong, I changed it here and there, and some things I did completely renew. But what is very recognizable is the rm-builder. As I seen it last, Rongs feeds it with an archetype and an array of data, and the rm-builder manages to create an rm-object from that. How I use it is about the same, but I use it recursive and I have a complex layer of software around it, and now, it should manage to eat every archetype. I publish the parts of it which are derived from Rong's code later. --------------- Thanks Tim for your thinking with me I hope I made myself clear, it is difficult to ask the right question and get because of that, the right answer. > If this is the case then you must be creating a new table for every > archetype (and every new version of it) used. In that case then each > table would be related to the archetype via it's ID. I guess I am also > assuming that you are storing archetypes in your repository as ADL or > XML serializations? This approach seems to me that it would take ALOT! > of source code in order to manage connecting the data rows back to the > archetypes. Hmmm, say a module for every archetype? > > If you could describe your data capture process a bit more as well as > your persistence approach it will help. > > Of course I cannot leave one of these types of conversations without > mentioning the utility of using an OODBMS for inherently hierarchical > data. :-) > > Cheers, > Tim > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
