On 18/02/2018 11:16, Erik Sundvall wrote:
When designing this, perhaps some (2-5) existing currently popular GUI
frameworks could be initial targets for output from the process, and
the selection could be updated over time. Perhaps for example
https://angular.io/ and https://reactjs.org/ are two starting
candidates for experimentation? (Both have partially declarative
design, but other suggestions are of course welcome) Then mechanisms
in those platforms could be reused rather than reinvented.
yes - this is the sort of thing I have in mind. The tool would function
as follows:
* represent UI forms and ?other UI behaviours (some screen workflow)
as archetypes+templates of classes that generically represent such
things
* use one or a set of templates to represent an application
* generate the OPTs of these templates, as ADL2 or JSON, YAML,
whatever is convenient
* perform OPT => GUI transform, injecting some UI styling profile
info, to get directly consumable artefacts for the UI framework.
experts on the UI side will be able to help refine the details of this.
THe 'smart split' of data / UI semantics will be the key to making this
workable.
- thomas
Also looking at the things done in the format used/shared by Marand
and DIPS is an interesting input for gathering requirements.
//Erik Sundvall
--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Team, Intermountain Healthcare
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog
<http://wolandsothercat.net/>
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
