2006/8/28, Bert Verhees <bert.verhees at rosa.nl>: > > > There is already a Java-based archetype editor available here: > > > > http://svn.openehr.org/knowledge/archetypes/dev/index.html > > Too bad, the sourcecode still is not published (last time I downloaded > it), I would like to see some improvements in (f.e.) error-handling. It > does never say why I ADL-file cannot be loaded, it just says it cannot > load it. There are many ADL-files, which it does not load, and I think for > good reasons, but it should say why. If it had sourcecode with it, I would > have repaired this, for my own use, because I have need for an > Archetype-editor which can also be used for debugging purposes.
The source code will be published as open source in the future, but we at Link?ping university haven't decided when that will be. The current Java ADL-parser isn't complete yet and many archetypes are still badly formatted. The parser is not too forgiving, so for example if there are missing parts in the description part of an archetype the parsing process will fail. This is mainly why many ADL-files won't load. Also, when an archetype fails to load it is often due to parsing errors but we don't output the errors given by the parser because sometimes they don't make sense at all. However, I am thinking about adding error outputs from the parser to a logfile. Another > good feature I would like to see is two way editing, in a GUI and in > ADL-editor, and see how changes on both sides reflect on the other side. > And another feature is support for more ADL-versions, not only the latest. > This could help migrate older ADL-files to newer versions. People who have > invested in previous versions now have to dive into the (for some people) > painful process of manually updating their ADL-files to newer versions. I have plans on making an ADL-editor that makes continuous checks as to whether the syntax is ok and marks the line number that the parser failed on, but this requires reloading of the edit buffer every time we want to show the changes in the GUI. It might become slow, but I believe it is possible to implement. However, there are many other things to implement before that, but it is definitely a good idea. Older versions than 1.3 (I think) of ADL isn't supported which depends on the ADL parser but I guess it would be possible to implement support for different versions. However, this would require to implement support for that in the ADLSerializer as well and not to forget it would require a lot of checking to ensure that semantics and syntax of these archetypes are correct. However, I don't believe there is any idea of maintaining the older (ADL version < 1.4) archetypes since they sometimes are inconsistent and faulty regarding to the reference model they are supposed to follow. I believe the current archetypes are the first ones that actually should be maintained since the openEHR project has suffered from teething troubles that are common to many large projects. At some point we must decide to migrate from older/obsolete versions even if it affects a lot of people, it is just a part of a natural evolution process for ADL. I am not saying the archetypes that have been used in older systems should be deleted, but there is no need creating more mess than needed. The older systems will eventually and inevitably have to start using newer archetypes in the future if they want to transfer and receive data to/from other clinical systems that haven't been around as long. So, except for not distributing the source-code, and to simple > error-handling, it is a very stable and good tool. I expect the > source-code to be published some day, because the creators indicated they > will, but they did, as far as I know, not indicate when. > > The archetype editor from Ocean, which looks as GUI about the same as the > Java-Archetype-editor, has sourcecode, and if you do not like dotnet-VB, > you can still use it to extract useful parts of the architecture, and > build your own in every language you want. The Ocean version has a few > instabilities. > > So there are two Archetype-Editors, both look about the same in GUI, but > both are build on complete different technologies. And both need > improvement. > I think there is a need for more, specially if there are improvements on > GUI-thinking. I know, all Word-processors look the same, and all cars look > the same, but is it the best way a car or Word-processor should look? Your suggestions on improvements are always welcome... We do not know, so I suggest that someone who want to build an > archetype-editor, should not look at those who exists, he could get > trapped in obvious thinking. We had a lot of ideas when building the Java archetype editor concering the GUI, but eventually decided to design it like Ocean's GUI. There are a number of reasons we did this, the most obvious was that we wanted to enable a structured overview of an archetype and this is why the different views in the editor was created. This was an obvious way to make it easier for a user to know what part of an archetype he/she is editing. In retrospect, the current GUI design is not optimal and it could have been designed in several different ways but we didn't want to compromise the usability of the program. For example if the entire archetype could be edited in a single view it could be to many things (buttons, floating toolbars, popup menus, commands, etc.) to keep in mind for the user. We have many plans for the editor and there had been discussions of adding another view in which the user can edit large parts of archetypes in a completely different manner compared to the current editing process. Probably a lot of things will happen in the future when other programmers can join an open source Java archetype editor project. Regards, Mattias These are only some suggestions from a rainy day in region of the South > Central France > > regards > Bert Verhees > > > > > Regards, > > > > Mattias Forss > > > > 2006/8/27, minreddy minreddy <minreddy at yahoo.com>: > >> > >> Hello > >> > >> I'm thinking to port Archchetype editor to Linux. > >> (As myself don't run windows at all) > >> > >> Are there any other dependencies other than ADL parser? > >> (adl_java_lib.dll) > >> > >> Any help will be greatly appreciated! > >> > >> > >> rgds > >> minreddy > >> > >> ------------------------------ > >> Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great > >> rates > >> starting at 1?/min. > >> < > http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/*http://messenger.yahoo.com > > > >> > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060828/bd6ed46b/attachment.html>
