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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081125/9f4d3aeb/attachment.html>
