-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mattias Forss schreef: >> This message was send too early because of the foreign keyboard layout, >> excuse me for that, I will complete it now (please delete the previous) > > ________ >> 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. > > Hi Bert, > > Sorry if this mail looks wierd, but I had to copy it from the mail > archive on the openEHR website since I didn't get the mail for some > wierd reason. I only got Erik's answer about publising the source > code. Sometimes mails get lost when using the technical list and I > don't know what's causing the problem. > > Anyway, I look forward to having more Java developers working on the > editor and I hope it could improve the editor a lot more. Hopefully I > can be inspired by other people's code and learn new things as well as > come up with creative solutions.
I doubt if you will learn many new things. But the product is very good and stable, and easy to handle. It showed me that it is possible to write responsive and stable interfaces in Java. That is a good thing. It will be of profit for the product to open source it. At this moment I am very busy on a very tight deadline, but it could well be possible in the near feature to work on the editor. > > The reason we haven't published the code is mainly that the code is > not that good looking (it is actually quite ugly) in many places and I > guess some people will have a hard time understanding the code, but good reasons to publish the code, I understand there is need for code improvement. As long as the object orientation is clear, code can be improved bit by bit. > there are also pieces of the code which are rather good. The quality > of the code may vary, but this is because we had limited time during > the Master thesis project and we decided to implement as much > functionality as possible instead of coding as neat as possible. This > was probably because we felt the need to fully complete the editor for > the final demonstration. When we started developing the pure > Java-based archetype editor we decided to use some existing code from > a Java archetype editor that was in development at the openEHR > repository. This editor used a wrapped Eiffel parser and that is why > it wasn't purely platform independant > > 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. 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. Except from my needs, which is at this moment, get a certain HL7 DMIM into ADL, I would think it is a good thing when a ADL-editor has a possibility for not to enforce the OpenEHR reference model. With all respect to the design of that model (clever people work hard on it. I sure want to follow that in the near future), I think it can be good if it is possible if people have good reasons to do something else with ADL, to facilitate that. So in this context, I think publishing the code will be very good. I hope it will be done in short time. regards Bert Verhees > >> 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. > > Yes, I do. > >> >> 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 a reload-button. I think a >>> kind of debugging facility would be a very good addition, and this I >>> regard as a debugging facility, also lading files with errors in it is. >>> Like Eclipse loads files with syntax errors in it. > >>> Which brings me to the following idea, I have read before in this list, >>> creating a ADL-editor plugin for Eclipse. > > Another tool that is good for debugging is the ADL Workbench but I > don't know the current status of that tool. Have a look at it if you > haven't tried it out. It's quite general and allows you to debug > archetypes that are using RM type names that don't follow any specific > reference model. Currently, the editor cuts away all information which > it doesn't recognize from its own knowledge of editable information > but this will probably be supported in future versions of the editor. > > >> >> 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. > > Exactly that was my idea, helping people to migrate, by giving support > in > loading previous ADL-versions, even if they are sometimes inconsistent. > It > is peoples own responsibility to handle this. > >> >> 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 > >>> You could prevent creation of more mess by not allowing them to save the >>> older versions, only load them. > > This is a good idea, at some point there shouldn't be a need to create > obsolete archetypes anymore. The possibility to convert old archetypes > to newer ADL versions is probably very usable and I hope it can work > somehow, but it might become hard for the editor to know which > versions of the kernel and parser to use for different 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. > >>> Yes I understand, the GUI as it is is very obvious, it is hard to think >>> about a better GUI, but different people have different ideas. Making >>> the >>> tool open source could allow experimenting with GUI's and produce >>> results >>> which are for us, now, unthinkable of. > >>> There is a VB-Archetype Editor, but I know there are many more >>> java-programmers then there are VB.NET programmers. > >>> Good luck with your product, I hope it will be open sourced soon. > > I hope so too... > > Regards, > > Mattias > > > >>> regards >>> Bert Verhees > >> >> 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 >>> >>> > >>> >> >>> >> >>> > >>> >>> >>> >> > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFE+L0Asr/NIrczD3MRArUwAJ9rI87/lgjnEK7gxzhzH4kEDNMAxwCdHwQ7 lurFfaJ4HJ2w0p2AuajLBSI= =RkUG -----END PGP SIGNATURE-----
