On 18-02-18 16:55, Thomas Beale wrote:
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.
I think I must have been run out of credit, since my emails yesterday.
But still I take my chance.
I must warn, Angular is a very complex environment, with much more
functionality then just showing GUI's. I am afraid you load a lot of
complexity which will not pay out. By the way, I thought that Marand
still uses AngularJS, I don't know how I got this information, but check
it before deciding for it. AngularJS which is the previous version, and
is in fact not further developed and not maintained.
This for generating Angular code or ReactJS code (which is even more
complex because it is a whole different paradigm)
There are many disadvantages of using a complex framework.
The disadvantage of using Angular or React is that it is not something
that works with easy generated code, except when you want to impose the
use of Angular to the OpenEhr developers, which will become
contradictory with the word "Open". I think it is best to offer the
developer as much freedom as necessary, it makes the effort to create
this also longer usable and ask for less maintenance.
Therefor I wouldn't go the way of an existing framework anyway, it is
much easier to generate javascript (as simple as possible) and GUI
identifiers together with the necessary REST-calls
The generated javascript can be quite simple, a GUI-control, an
identifier to read the content, and a REST-call which uses the content
to do its thing.
When developers want, they an copy and paste the generated javascript
into their web-framework in order to maintain the own graphical layout
and application functionality around the generated code.
Integration will become much easier.
You could optionally make it more complex (as a second step goal) and
still work for the simple copy/past situation. This complexity could be
in validating datasets in the browser by Javascript/Typescript, so there
will be only network activity when the dataset is validated and OK. That
would really do the user-experience good, especially on mobile devices.
But this second step could be a later target, first having the simple
javascripts generated and the REST calls generated would be a good
target to start with.
Best regards
Bert
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
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
