Tim Cook schreef: > On Wed, 2008-04-23 at 17:11 +0200, Bert Verhees wrote: > > >> I want to hand this archetype with data, for example from a webform, or >> a message interpreter to my kernel which knows what to do with it. >> > > ... > > >> Anyway, this XML file will be given to the RM-builder, together with the >> ADL-file, and the rm-builder should be able to validate and create good >> RM-objects from this. >> >> That is my idea, but I don't know if it is a good idea >> > > Hi Bert, > > I hope your bike ride was inspirational. :-) > Thanks, it was inspirational, in a poetic way. Spring is coming up, flowers, birds, sun carefully shows her face between dark clouds But now back on the job. > But now that I believe that I understand where your problem lies, I > believe that Peter correctly analyzed it by sending you the link to > Persistence on the openEHR wiki. > I think, you understand it almost.
The problem is not the persistence layer, my RM-objects are able to save themselves in a transparent way. Even if I change the database to an objectdatabase below, nothing will change. How my RM-objects save their selves is not rocket science, but it was a lot of work to get this efficiently done. So I keep this to myself for the moment, must make a living out of it. Simply said, they have a method to do so. If I would take a database like Cache, I could use the same interface. Also the protocol does not make a difference to the interface, jdbc, odbc, API's, you name it, changed in a short time. This is good news for eventually buyers of my product. (just emphasizing the qualities of my product, hope you don't mind) The problem is indeed in the below section of your reply. > From your example maybe you are attempting to be too much of a > reductionist as far as stripping down the XML? > > Because of my choice of approach, I don't think that I have any more > thoughts to contribute on this. > > Mostly because I think that going through the steps of: > > 1) create an object from the ADL for the UI > 2) add the data in the UI > 3) validate the data > 4) break the object back down to a serialization > 5) map the serialization to your persistence layer > > then to edit: > > 1) create an object from the ADL for the UI > 2) retrieve serialized data > 3) map the data to the object > 4) edit the data in the UI > 5) validate the data > 6) break the object back down to a serialization > 7) assign the new version to the serialization > 8) map the serialization to your persistence layer > > is very application code intensive. > until here, because, here is where I want to keep the database-type transparent. This is important to me. So I was thinking about a solution for handing over the leaf-node-data to the kernel, and in the same way, make this in more ways functional, so that with not too much code and also generic code the (G)UI handling, machine-interface handling can be done. That is what I am looking for, and I need to make a decision in short time. A few months ago I saw a discussion about XForms here, but I did not read it because lack of time. I will do that now. Thanks for helping me defining my problem, if you have something more to add, please do regards Bert Verhees > Whereas using an object database: > > A parser utility outside of your application is used to parse a set of > serialized archetype definitions into objects one time and they are > stored in an object repository. > > 1) retrieve the object(s) from the repository > 2) add the data into UI > 3) validate the data > 4) store the object > > then to edit: > > 1) retrieve the object from the database > 2) edit the data in the UI > 3) update the version information > 4) store the new object > > Tuning for performance is done by selecting at which levels your objects > inherit from the database persistence machinery. > > > I wish you the best in solving your persistence layer mapping. > > Cheers, > Tim > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
