Hi Paplo, Your suggestion here is too oriented to GUI uses cases. As Tom indicated, pass_through is intended to support other data oriented contexts such as flattening schema and class hierarchies, this is why is was generalised from hide-on-form as used in the template designer. If you look at the Operational Template exported in the Template Designer there is an AOM extension of view-constraints which structurally are the same as annotations where there is a hash of paths of hash of constraint name. This supports the pass_through constraint and any other constraints of this class. The term view was adopted because it is used in both GUI and data oriented contexts. I can provide the XML schema for this AOM extension used by the template designer if people are interested. Heath On 10/01/2012 11:47 AM, "pablo pazos" <pazospablo at hotmail.com> wrote:
> 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 <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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/164f0a7f/attachment.html>
