>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. 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 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. > 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 >> > >> >> >> >> >> > >> >> >> >
