My two cents, an opinion on a detail issue
The 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
wrote:
Send openEHR-technical mailing list submissions to
openehr-technical@lists.openehr.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
or, 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 cour
