Hi Hugh, I am not in my brightest state of my mind at the moment, so I may deny that the following belongs to me when I wake up in the morning... I think I can build a GUI automatically without instantiating a single RM class at all. The reason is; the archetype gives you all the information about the types you'd expect from input. The mappings from constraints to GUI elements is mostly a one time job: coded text to combo boxes, free text to text boxes, duration to some more specialized widget, amount to a textbox with a combobox for unit etc... (this is pretty much what Ocean's archetype editor seems to do, but of course the classes in that source code are not as well seperated as the java ref impl) Whatever the value is given, the input from GUI can be validated via AOM instances, right? I know the constrained RM type in AOM, I know the constraints is must satisfy. So the moment I'd create the instances would be after gui generation, data input, and validation via AOM instances. At that time I have constraint fullfilling data which can nicely be placed in a RIM instance. For persistence, the archetype is still the deriving force, since to create a structured set of RM instances, you need the AOM tree anyway, because that's where the structure is, and since every node in AOM has its path, a tree with (node, value.toString()) tuples is all I need for simple persistence :) So, with some extra coding, It seems possible to parse an archetype, generate a gui, validate input and save data without using RIM classes. I'm not saying that this is the right way to do it, it is just that the role of the RM classes seem to begin "mostly" when you start coding business logic. Again this is about the java ref. impl. Other implementations may assign more behaviour to RM classes. The feeling I get is, the whole thing is really archetype driven (and is it not the point anyway?)
Many thanks for the feedback, and I hope I did not confuse anyone... Kind regards Seref On Tue, Nov 25, 2008 at 10:20 PM, Hugh Leslie < hugh.leslie at oceaninformatics.com> wrote: > Hi Serif > > I would have thought that if you wanted to persist data and retrieve it so > that it conformed consistently with the archetype, then you would have to > invent some model of persistence which would have at least some if not all > of the characteristics of the RM - so why not use the RM! You even said > that you are parsing the archetype and building instances of the RM > datatypes in memory... > > Not sure how you would do it otherwise as the archetype is just a model of > constraint on the RM ie when we are building forms for instance, the widgets > conform to not just the archetype, but also the underlying RM and are really > archetype constrained versions of RM instances but in a GUI model. ie. A > quantity for systolic blood pressure on the form is a quantity widget that > conforms at some level to the RM but is constrained by the archetype to mean > systolic with units mmHg and range 0 to 1000 etc. > > regards Hugh > > Seref Arikan wrote: > > Hi Tom, > Thanks for the correction of the term. Yes I'm referring to runtime usage > of archetypes. > After taking a look at the RM class code in ref. impl. I guess it is safe > to say that some RM classes seems to check for proper values, and that's a > reason to create instances of them. I guess this is where syntactic checks > about captured data are done. > Also almost any business logic written against the reference object model > would require interfaces of these classes, so their instances would be > needed in any case you have data to process, so even if I could avoid them > for a very simple case, I'd need them again for making any use of data in > software. It takes some coding to see their use :) > > Thanks for the response. > > Kind regards > Seref > > On Tue, Nov 25, 2008 at 5:43 PM, Thomas Beale < > thomas.beale at oceaninformatics.com> wrote: > >> >> Hi Seref, >> >> I think 'lifecycle' is not the term you want, since most people use that >> to mean 'authoring lifecycle' i.e. the authoring, review, approval >> history of an archetype. Here we are talking about the runtime usage of >> an archetype. If I understand correctly the question it is: can the >> runtime instantiation of the Java RM objects be avoided in some simple >> circumstances? It seems unlikely to me, because most of the RM classes >> have some routines that would be commonly used during data capture, e.g. >> have a look at the History package in the data structures part of the >> model - >> >> http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109157527311_729550_7234Report.html >> >> - thomas beale >> >> Seref Arikan wrote: >> > Hi, >> > The term lifecycle may not be appropriate for archetypes, and >> > suggestions for a better term are more than welcommed. >> > Assuming that we constrain our interest only to a set of information >> > encapsulated in a single archetype, would you provide the technical >> > lifecycle you can imagine, for an archetype? The scenario is very >> > simple: an archetype is loaded from disk, displayed on screen, and >> > after data is provided by user, data is saved on disk, later loaded >> > and edited, and saved again. That's it! >> > >> > To better explain the context of the question, please think about the >> > java reference implementation. I'll skip some minor steps and give my >> > own points, and I'd like to hear yours. >> > >> > 1) Archetype is created via a tool like Ocean's designer. >> > 2) It is loaded by the parser in the java ref. impl. >> > 3) It's in memory representation is parsed, and know we the >> > constraints on rim data types expressed in java language terms and >> > instances of these terms in memory. >> > 4) Assuming we are creating a gui only for an archetype, we can create >> > a form using the constraints on data types, and Ocean's tool has an >> > interface tab that does it. >> > 5) A user provides information using the generated form. >> > >> > 6) We can check the validity of the data entered using the in memory >> > representation of archetype, like dates, amounts being in allowed >> > interval, and simply warning user if any data is not valid. >> > >> > Things become interesting after this point. In the context of the java >> > reference impl. and immutable rm classes, we can now create rm >> > instances since we now have data, and we can persist them. If we were >> > think of the simplest use case of just storing information and loading >> > it back, would we need RM instances here? How about saving a custom >> > represention of user input like an xml file to disk, and reading back >> > for updates? As long as the link to original archetype is preserved, >> > updates can be checked for validity. >> > >> > In short, I'd be very happy to hear your description of the flow for a >> > very basic scenario "in the context of java ref. impl". Especially how >> > you'd use the RM classes (in immutable/mutable form) and when. >> > >> > Those of you who are active in development of archetype based systems >> > can provide very useful feedback for others to follow >> > >> > Kind regards >> > Seref >> > >> > Ps( the use of templates is deliberately excluded here, to keep things >> > within a smaller scope) >> > >> ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > openEHR-technical mailing list >> > openEHR-technical at openehr.org >> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > >> >> >> -- >> *Thomas Beale >> Chief Technology Officer, Ocean Informatics >> <http://www.oceaninformatics.com/>* >> >> Chair Architectural Review Board, /open/EHR Foundation >> <http://www.openehr.org/> >> Honorary Research Fellow, University College London >> <http://www.chime.ucl.ac.uk/> >> >> >> * >> * >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > > ------------------------------ > > _______________________________________________ > openEHR-technical mailing listopenEHR-technical at > openehr.orghttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature > database 3639 (20081125) __________ > > The message was checked by ESET NOD32 Antivirus. > http://www.eset.com > > > -- > > ________________________________________________ > Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI > Clinical Director > Ocean Informatics Pty Ltd > M: +61 404 033 767 E: hugh.leslie at oceaninformatics.com W: > www.oceaninformatics.com > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081126/ecfdfa3a/attachment.html>
