I wrote this afternoon, and I see that it is not sufficient. It could work for archetypes, because the have clear and simple identifiers which could be used to connect the generated component-values and parameter-naming inside the generated rest-calls inside the javascripts, but it would not work in representing query results.
So I came to another idea One could also create path-values in JSON, in that way there would be only very simple rest calls necessary with only a few, or maybe one parameter in the rest-calls, the JSON-structure and maybe one or two more which I have not thought of yet. In this way, every archetype datavalue-set can be represented, and also every query result. And the rest as described below remains in that case about the same. But I am sure there are very good ideas of others, so I wait sometime to get a point of what is generally agreed about. Best regards Bert Op di 20 feb. 2018 17:05 schreef Bert Verhees <[email protected]>: > 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 [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
