Hi Thomas, good clarification, although too much in detail at some
points in this moment of thinking about it.
I see it as more simple,
1) about the classes, it would be nice, in my opinion, if they can stand
alone, without needing other RM-classes. I think this will makes life
easier in the future.
2) about XUL, the workout is very usable, and it defines, as I read, in
a standardized way GUI-components. I don't know if XUL also offers ways
to constraint the input in the components, if not, then that is a
shortcoming. We need to solve that. It will be so good for the user
experience if validation of component content can be validated client-side.
3) The targetting to frameworks (like Angular or (stupid simple)
javascript), I think that is something for the community to write, we do
not need a standard for that. As contribution to the community I (or
some else) could write a tool to generate very simple javascripts which
instantiate the GUI-elements, activate the constraints for them, and
gather the validated contents of them to the REST-calls, or in case of
displaying data, retrieve them from the REST calls and spread them over
the components. Such simple scripts could be used in almost any
framework by just adding the URL of that script to the target (maybe
Angular, simple HTML or any other framework.) Also important is that the
Javascripts do not contain CSS, so that styling will be imposed by the
container which links the script. This makes it usable in all platforms
without any target defined in the presentation-archetype.
Visually testing those Javascripts is very easy.
There is no need to define datasources, because the REST calls handle
that, even for AQL this could be possible to work that way. In fact, it
is how 99% of the Javascripts-frameworks do their job.
Bert
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
