My two cents, an opinion on a detail issueThe disadavantage of Vaadin may be that it is server based, most of the logic runs on the server, and this makes an application less scalable and causes more network traffic. This is because data-validation is done on the server and the result send back to the client if there is a problem. Especially on slow networks this can be a big problem. And you will be amazed how many slow networks there are on the world, not in an university, but in villages in the South of France or the North of the Netherlands, also South America, Africa, Asia, but also in parts of Kansas, Oklahoma, West Virginia, most people on the world, when they have Internet, they have it on a slow network.
When you want to make money, you will need those people as client of your products. People have tablets, IoT-devices, they are doing a lot of their own healthcare, that is the near future coming.
Better would be better to validate data on the client and only send data to the server if it is valid. Only UID's needs to be validated on the server, because for validating UID's server-knowledge is needed. But for data-against-archetype-validation, most of the validation knowledge can run on the client, and GUI can respond instantly on errors. That is what we want, we don't want a delay of three seconds to tell us that the heart-rate figure is not realistic.
Of course, this causes some problems, but it is not impossible. For this purpose it is needed that validation-software needs to run on the client. One can think of Java-validation-software, but that causes all kind of permissions that need to be given, and it creates a dependency to the JVM version on the client. So that is also not desirable.
Clients all run Javascript, and better, the superset Typescript. So it would be good if archetypes/templates could be parsed client side. The server only would need to send the smart minimalistic form-description and the template, and wait for a valid dataset result.
The client would create a form from the description, parse the template/archetype/validate the data and only send back the result.
Think about it, there is need for an Archie-library based on Typescript. A good starting point, check here
https://github.com/antlr/antlr4/blob/master/doc/javascript-target.md I am very interested who will take up the gauntlet Best regards Bert Verhees On 06-02-18 18:42, Ricardo Gonçalves wrote:
On the "putting together a web frontend and a Java backend" topic, it may be interesting to look at Vaadin, which is an open source framework to build web applications using Java (you code everything in Java, an equivalent GUI is generated and all behavior that comes from user interaction is actually triggered on the backend through a protocol like RPC; pretty much like the old GWT but smarter and with less boilerplate code). They also have a dev preview on something called Flow, which is supposed to give a Java backend direct access to the DOM, somewhat similar to real-time server-side rendering but with an optimised communication protcol instead (no need to care about APIs, REST, whatever). Anyway, since we're already on a Java ecosystem, those may be easier than modeling APIs and adopting JavaScript frameworks that may or may not be alive tomorrow.Att., Ricardo Gonçalves.On 06/02/2018 15:00:31, openehr-technical-requ...@lists.openehr.org <openehr-technical-requ...@lists.openehr.org> wrote:Send openEHR-technical mailing list submissions to openehr-technical@lists.openehr.org To subscribe or unsubscribe via the World Wide Web, visithttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.orgor, via email, send a message with subject or body 'help' to openehr-technical-requ...@lists.openehr.org You can reach the person managing the list at openehr-technical-ow...@lists.openehr.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openEHR-technical digest..." Today's Topics: 1. Re: Announcing Archie version 0.4 (Thomas Beale) ---------------------------------------------------------------------- Message: 1 Date: Mon, 5 Feb 2018 19:04:35 -0300 From: Thomas Beale To: openehr-technical@lists.openehr.org Subject: Re: Announcing Archie version 0.4 Message-ID: <5e6cf155-c2ea-cf69-a8d0-402ed025c...@openehr.org> Content-Type: text/plain; charset="utf-8"; Format="flowed" yes, JS = javascript, TypeScript etc. No, nothing to do with Java of course. Just that JS/TS are the languages that seem to be popular for web app development these days, and Java for the back-end. The connection between front and back-end that people seem to prefer these days is REST APIs, which both Java and JS can do easily enough. - thomas On 03/02/2018 07:56, Peter Gummer wrote: > On 1 Feb 2018, at 05:13, Thomas Beale > > wrote: >> >> ... But the main interest is that we will be able to build new tools >> such as a Java/JS replacement for the ADL Workbench, and of course >> things like a high-quality, BMM-driven runtime archetype validating >> kernel for EHR systems, workflow implementations and many other >> components. >> > > Hi Thomas, does ?JS? stand for JavaScript? If so, I don?t understand > how Archie (written in Java, disappointingly) would enable JavaScript > implementations. JavaScript has nothing in common with Java (apart > from the name). > > Peter > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org-- Thomas Beale Principal, Ars Semantica Consultant, ABD Team, Intermountain Healthcare Management Board, Specifications Program Lead, openEHR Foundation Chartered IT Professional Fellow, BCS, British Computer Society Health IT blog | Culture blog -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org------------------------------ End of openEHR-technical Digest, Vol 72, Issue 4 ************************************************_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
