Thanks Mattias for your answer. I keep it short, now, the weather has improved, and I am on holiday ;-) and the keyboard-layout still is French, which causes me to search every character.
> 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. I think you probably know that publishing source-code in a early stage has advantages, this is specially true when one wants to publish it anyway. It allows others to implement features they need, and you can keep control by being the administrator of the CVS system, and hide forks you don't want. F.e. this is facilitated in sourceforge.net. This is why I don't understand that you do not publish the sourcecode now. But I am sure you(or the university) have good reasons for this. > > 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. This would be a good addition, and opening the logfile-window after failure, it could help someone to update older ADL-files which for now he has to update manually, and has no way to check in detail which small thing he forgot to change. As being a programmer I think, you know exactly what I mean. > > 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. You could an automatically reload replace by > > 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 >> > >> >> >> >> >> > >> >> >> >
