If it is really needed for the moment for representing templates then it's OK with me (as long as we agree that this is a temporal thing), but I still feel that having two separated places to rule UI generation is a bad idea. I think that annotations could work for you (even creating a new specific ADL section would). We currently have all the GUI directives for representation in a documentation file for each reference model (as you can see in this screen capture http://i.imgur.com/tQxRt.png). This could be extended to general templates in similar way to the one that Pablo has posted. on the other hand, EHRFlex uses a complete MVC architecture, in which the intermediate model (which also depends of your RM) is the one responsible to transform archetypes/templates into classes that the 'view' part can then paint.
2012/1/10 pablo pazos <pazospablo at hotmail.com>: > Hi Diego & Thomas, > > I think this should be out of the scope of the new semantic/structural > archetypes & templates specs, and should be included in a new specification > of GUI Templates. > > I been working on this subject for a while and want to formalize a XML > format to have GUI directives / GUI definition (input controls, position, > visibility, order, ...) and binding with structural archetypes and templates > (in a system this bindings should be to OPTs). > > http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates > > On february/march 2012 I'll be working on this to improve the flexibility of > our current templates: > http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn%2Ftrunk%2Fopen-ehr-gen%2Ftemplates%2Fhce > > If anyone want to work on this, would be a pleasure to colaborate. > > FYI: We have developed a prototype editor for those GUI templates: > http://code.google.com/p/template-editor-open-ehr-gen/ > It is web based, and can access archetypes repositories via HTTP to pull > archetypes to be included in a GUI template. > > -- > Kind regards, > Ing. Pablo Pazos Guti?rrez > LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez > Blog: http://informatica-medica.blogspot.com/ > Twitter: http://twitter.com/ppazos > > ________________________________ > Date: Mon, 9 Jan 2012 19:03:32 +0000 > From: thomas.beale at oceaninformatics.com > > To: openehr-technical at openehr.org > Subject: Re: pass_through attribute in ADL 1.5 > > On 05/01/2012 08:54, Diego Bosc? wrote: > > Put a couple of comments on the wiki, but I think it is a thing that > should be discussed on the list. > In ADL 1.5 a flag 'pass_through' was added. Its definition is 'Allows > nodes required for structuring data but otherwise redundant for screen > display and reporting to be detected by rendering software'. So now we > have a GUI directive on the ADL. Shouldn't this be a part of the > reference model information (if it is never supposed to be displayed) > or part of a 'visualization template' (another different level). > I would say that more information about visualization will be needed, > and having visualization information separated between two different > places feels like a bad design move. > > > In general I am inclined to agree, and I have to say I have been in two > minds about having this attribute in there. I am convinced by clinical > modellers who say that something is needed to control interior tree nodes > not appearing on the GUI (indeed, it is visual pollution). And - even if the > template were being used to build a message definition (generated XSD or > similar), and the data were processed into some report or other output, this > attribute would be respected (technically, this is still 'user interface'). > > I know the passthrough attribute is used often from the current .oet > template usage, so we need a way of dealing with the requirement. If we take > it out, and say it is a GUI directive, the problem is we currently have no > formal framework for that yet. Maybe the lesser of two evils is to do what > Koray (I think?) said, and make it a special kind of annotation. I have > implemented annotations in ADL/AOM 1.5, and they work nicely. We need to > agree on some kind of standard representation, e.g. > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
