Mattias Forss schreef: > 2006/9/2, Bert Verhees <bert.verhees at rosa.nl>: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Mattias Forss schreef: > >> > We used (and modified) parts of the code from the existing editor >> > which was used as a facade against the openEHR archetype object model >> > since that model is immutable. On the other hand, I don't think that >> > this code is easy to understand even if you understand the API for the >> > Java kernel. When we open source the code for the editor I suppose >> > there might be questions if the facade code is worth using anymore or >> > if it should be replaced with a better API that could be used as a >> > facade for the archetype object model. >> >> I don't know what you mean in this, I think the best way to write a >> archetype editor is to directly use the java-kernel-code. >> I see some people want to rewrite the adl-parser, but, in fact the >> adl-parser is in its source quite clear and good. > > We cannot use the kernel code directly unless we make changes to it to > be mutable (changeable). The reason for this is because whenever you > want to alter things, the Archetype object has to be rebuilt all over > again because it is not allowed to be changed. Using the kernel code > directly and rebuilding every time some small thing has changed would > be very slow (especially very slow response in the GUI). However, I've > heard of a new technique that could be used in Java to be able to do > this a lot faster, but I'm not sure if it will solve all the problems > in this case. I think there are other solutions. As I told you, I generate ADL files from XSD-files, and I had about the same problem. Took me some time, even did some experiments with using copy-objects, but finally I found it. It takes some logic from the other way around thinking, but I think it is possible to use the kernel-code and leave the Archetype-related objects immutable. I don't say it is exactly the same problem, but the point is, built your objects, build your main-object, but just before it is finished, built your attribute-objects, and just before they are finished, build your children objects, and so on and on. And when there is nothing to build at the bottom, you finish the building of the higher in hierarchy objects, so go back on your steps, and you end with finishing building your archetype object.
This all happens in memory and therefore has no big load on the process time, and when it does take to much time, create a "Process Changes"-button, to make the actual building of everything a user-action. This then makes it also possible for synchronizing GUI-objects and ADL, and allow working in ADL (which has, of course then, syntax highlighting), and after the "Process Changes" update the other GUI-parts, like your design-page, and also your GUI-builder, which is a very nice feature. > >> >> For me it is necessary to work also outside the reference model, but in >> ADL. It is a bit complicated to explain, Maybe read my previous mails. >> >> So I need a archetype-editor which loads ADL-files, and does not enforce >> or check the referene model. I translate HL7 XSD-files directly to ADL, >> that is to say, I am working on that, and the improvements give hope. >> >> The thing I miss is to viualize my ADL-files, so I have to check/debug >> them manually, which is hard. I could use the code of the archetype >> editor to change it for my needs, maybe it is not hard to do, but maybe >> it is, as I read about ugly code now. > > This would require a feature in the editor to chose an "unknown" > reference model (which you can give a name) and maybe also specify > that reference model's semantics. It could be really messy working > with unknown reference models, and hard to come up good ways to > display things in a GUI. Since any rm type name can really constrain > any data type (text, boolean, date) even things there aren't any > corresponding controls for. Yes, it is a challenge, and maybe I can do that on my own, and that way better explain what I mean. You are right, there must be some constraints, but they do not need to be OpenEHR related. One could for example use it for other companies with complex data-objects that need flexibility, but I must think about that before I explain it further. It is just a fantasy. But anyway, I need now to store the hundreds of CMETs which populate a average DMIM, and translating XSD to ADL makes it possible to use OpenEHR as storage machine for HL7, which it will be in a transition phase. later we are going to model everything to the real OpenEHR reference model. Which off course has many advantages above HL7. But in fact, that is not my profession. I do not have much knowledge of medical informatics. My wife has, but until yet it did not seem to be contagious. So I leave that to someone else who has very wise thoughts about that. But we are in a hurry, that is why I generate most of the code, and make a HL7 storage machine, which takes much less time then model a OpenEHR information model, and stick it together. > > I have almost finished implementing an ADL-editor, (in the formats > view of the archetype editor) which could be used to edit whatever the > parser accepts, but whenever the ADL is reloaded in the GUI, all > things not corresponding to the openEHR RM (and things that aren't > recognized as editable in the GUI) will disappear. I believe you could > use this ADL-editor as a start, since it marks the line number that > the parser fails on, but the downside is of course that you would have > to do things manually. On the other hand, I don't think it's easy to > create efficient GUIs for unknown reference models, since class and > attribute names always have to be specified, unless of course one > creates a really smart GUI that follows defined RM semantics which > configures the widgets' functionality. Sorry, I talk to much, but you are right, there are some challenges to be solved, which give the thing new possibilities. I like to work on that, in the near future. It will be a unique piece of software. Also the possibility to import XSD, will be good. Who will ever need XMI again, which never is really accepted as a standard, every vendor fantasizes his own extension, in a hurry to let no one share has objects. OMG made a exchangeable object-language, and everyone uses it to exclude other vendors. ADL is not only exchangeable, but also better, because it has the possibility to exchange semantics and terminologies also, and as you do, create rudimentary interfaces. There must be more market for this, except from the medical market. OK, I leave it here, and stop dreaming, and do what I am supposed to do for the next few weeks. I hope the source code will be published soon. I can build it on my own, but it is too much effort, and why do something which is already done. Regards Bert Verhees
