Hi everyone, I've been a silent follower of this list for a long time. Nice of Koray to give me that little nudge to ease me into participating in the discussion. Much like pushing one into the dancing ring at a club party.
It's comforting to know a lot of us are in the same boat. I haven't yet had the chance to check out what the other folks are doing (so apologies for my ignorance) re: GUI generation/customisation but in the meantime I can offer our (GastrOS) side of the story. It seems like a lot of the discussion has been around "where" the specification of the directives should go in the modeling process. While this is an important discussion, my focus as a pure software guy (i.e. a "heathen" wrt the clinical domain ;) is in the lower-level question of "how" the directives should work after all. It's probably worth noting that GastrOS generates GUI widgets dynamically at run-time: the widgets live and die in machine space, i.e. no code-generation etc. Effectively the heart of the GUI generator is a rule-based engine that processes the archetypes and spits out different GUI forms for different types of RM objects, then binds the forms to the RM object instances that live in the runtime environment. You could think of the generated GUI forms as "faces"/views of the RM object instances. So these rules I mentioned above are programmed into the GUI generator logic, e.g. textbox for DV_TEXT, combobox for DV_CODED_TEXT, a flow panel for CLUSTER, etc. These rules are also "compositional" in that they allow for recursive structures, so CLUSTER containing CLUSTER(s) maps to a panel containing panels, etc. Now I can introduce GUI directives into the picture. Basically the directives are specified as template-level annotations, and the semantics of these directives are also programmed into the GUI generator logic. So the GUI generator has a fixed vocabulary of directives it understands and performs appropriate "alterations" to the way it normally produces widgets. So this approach works sufficiently for our purposes. And Koray & I have tried to define the set of directives to cover as much of the basic GUI customisation needs of the general audience as possible. E.g. organising large structures into multiple columns and tabs, showing/hiding complex concepts, allowing the option to render the same data type as different controls (DV_CODED_TEXT as combobox or radio buttons), etc. But we know this is a very finite set, and if we were to cater for more complex customisations (especially when it comes to customising _behaviour_ on top of just appearance) we would need to keep programming them into the GUI generator. What I have been dreaming up is a way to "dependency inject" the directive semantics such that the power of specifying new GUI directives lies in the user of the GastrOS framework, not the developer. Sort of like how you customise Eclipse through plug-ins. So this is as far as my thought process has gotten to. I hope this all makes sense. Apologies for making it rather long and windy. I know you're all busy people! Would be very happy to hear comments about this, and I guess once you guys have the actual source code to play with, you might be able to shed more pointed insights. Getting GastrOS up on sourceforge is definitely at the top of our priority list and you will hear from us soon ;) all the best, Hong Yul On 2/12/2010 3:34 p.m., Koray Atalag wrote: > > Hi All, late to respond but here are a few thoughts: > > -While having ?another layer? of modelling to handle presentation I > think we already have enough of those layers. I believe the common > sense of doing this will be to sort out the GUI Directives stuff we > all have come up with and do a careful analysis (led by the core team > of course). Decide which ones are ?universal? and which ones are > data-set specific. Then like annotations in templates invent new > optional keywords to accommodate these. The operational template will > then contain everything an application would need to function. > > -I strongly believe that the presentation information should not be > separated from data-set definitions ? templates. As archetypes and > templates are designed to handle ?/change/? this means that the model > will be on constant change so maintaining two models ? kind of shadows > of each other does not make sense to me. Perhaps not so good design > from a puristic point of view ;) > > -I am also pretty sure that with a handful of those GUI directives we > can cover %80 of all presentation requirements in any clinical domain > ? we?ll worry about the rest later on. So it may well be the case that > some of these directives may become concrete and be part of the > specifications ? which will boost consistency among different > implementations. > > -I also think while thinking on these issues we should also have a > look at other facades of GUI ? such as implementation technologies, > Web/client forms and MVC etc. methodologies. These may have an > influence on the directives we will likely to come up with. > > My 4 cents...Cheers, > > -koray > > P.S. Our developer Mr. Hong Yul Yang (also an awesome pianist!) now > has a good understanding of openEHR and I think he has much to > contribute to this community...he gave a good deep thought to the > above implementation technologies and MVC approach before going on > with GastrOS. Hong Yul I think it is now time to talk for yourself ? > don?t be shy! And people don?t hesitate to ask all your hard questions... > > *From:*openehr-technical-bounces at openehr.org > [mailto:openehr-technical-bounces at openehr.org] *On Behalf Of *Thomas Beale > *Sent:* Thursday, 2 December 2010 2:45 p.m. > *To:* openehr-technical at openehr.org > *Subject:* Re: GUI-directives/hints again (Was: Developing usable GUIs) > > On 02/12/2010 01:33, Tim Cook wrote: > > On Thu, 2010-12-02 at 00:50 +0000, Thomas Beale wrote: > > > > > This is one of the most common uses of templates we are finding. > > So somehow knowing the possible choices somehow affects the actual code > in the field you are querying? > > > in theory no, but it could affect what you consider to be correct. If > you knew there were only 3 possible codes due to a template that had > been used, then you might query directly using those codes, rather > than the 20,000 allowed by the archetype. > > > I can imagine other thing, e.g. coding of fields that were just > > DV_TEXT in the archetype. > > > While I still think that this is a bad idea anyway. After all; it is > either free text or coded text. Pick one. I still don't understand how > knowing what set was available is meaningful to the code chosen. > > > well the user often picks whether to code or not; a quite common > visual control is one that allows either to be entered. So the > template might define a preferred value set of codes, while still > allowing for plain text. The archetype probably only had the plain > text constraint. If you have the template at hand, you could do some > querying based on the knowledge of the code subset used by the template. > > > In ADL 1.5-land, a template is just another layer of archetyping, with > > some extra features. > > > I still fail to see the need. It seems to me to be a useless layer of > complexity. But, I am still interested in a use case where templates > are 'needed' to 'fully interpret' the data. > > > you mean the need of having the template to interpret the data? You > can undoubtedly do it without the template. But since a lot of coding > is defined locally, I think it is going to turn out to be useful. > > > This is distinct from any 'visual template' stuff, which I agree > > should be a distinct artefact and probably formalism. > > > And this level is dependent on implementation choices. Only > applications built using the same framework can share these templates. > If an entity is going to dictate presentation options and layout then > they are likely (IMO) going to do so in the context of the same > framework. > > * > *sure. This would imply yet another technology-independent formalism, > if gui directive templates are also going to be portable. > > - thomas > -- Hong Yul Yang Research Programmer Department of Computer Science The University of Auckland Office (tamaki): 731-339 Phone: +649 373 7599 x88237 http://www.cs.auckland.ac.nz/~hongyul -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101203/44c32fd4/attachment.html>
