Re: Templates for application form development

Jussara, Here is a copy of the paper we presented on INFOLAC 2014 https://www.slideshare.net/pablitox/generacin-automtica-de-interfaces-de-usuario-para-sistemas-de-informacin-clnicos-basados-en-una-metodologa-multinivel The presentation

Re: Templates for application form development

I didn't change my mind, I was just not precise when I said that ;) - t On 20/02/2018 23:29, A Verhees wrote: So splitting up the RM instead of making it larger would be my idea. The first is not easy to do, but the second is, and helps us avoiding further problems and avoiding

Re: Clarifying - Templates for application form development

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

Re: Templates for application form development

> > So splitting up the RM instead of making it larger would be my idea. The > first is not easy to do, but the second is, and helps us avoiding further > problems and avoiding creating unnecessary large libraries. > > > We are not intending to make the RM any larger, not sure why you think we >

Re: Templates for application form development

My problem description was good, the solution, is not really good. In fact the metaphore of circles does not work completely in openehr. I believe it is the other way around. All higher level classes may use the datatypes, but datatypes may not use the higher level classes. So datatypes must be

Re: Templates for application form development

I must have missed new developments, I am still working with RM 1.0.3 which, I was thinking, is the production version My remarks were for that version, and for my idea, there were some inconveniences in it. But I will study the new RM, and if I find some similar inconveniences, I report

Re: Templates for application form development

On 17/02/2018 21:53, A Verhees wrote: I know Thomas, but they have dependencies to other classes in the RM. To data types, to support. that should not be the case - that's exactly what we are avoiding. If we missed something it is an error. But note - most of the RM 'Support IM' model

Re: Templates for application form development

We're still working on this somewhat , using Task Planning as the excuse to finally get it right On 20/02/2018 16:44, Diego Boscá wrote: These rules/assertions are things we can express with the AM right now,

Re: Templates for application form development

Templates have no information about user interfaces, are mainly full document data structures + semantic definitions + constraints + terminology (local and bindings). User interface information includes layout, form composition, position, size, style, etc. Clearly this is not included in current

Re: Templates for application form development

Let me look for it, haveit on a backup disk somewhere :) On Tue, Feb 20, 2018 at 9:59 AM, Jussara Macedo Rötzsch < jussara.mac...@coreconsulting.com.br> wrote: > Could we have access to that Pablo? > Regards > Jussara Rotzsch > > Em dom, 18 de fev de 2018 às 15:58, Pablo Pazos

Re: Templates for application form development

These rules/assertions are things we can express with the AM right now, right? :D El 20 feb. 2018 5:37 p. m., "Thomas Beale" escribió: > > On 19/02/2018 10:47, Pablo Pazos wrote: > >> IMO annotating templates with UI info is not a good idea. A layered >> approach is

Re: Templates for application form development

On 19/02/2018 10:47, Pablo Pazos wrote: IMO annotating templates with UI info is not a good idea. A layered approach is much cleaner and scalable, i.e. to define a new artifact on top of current templates / archetypes / RM (these are also examples of layered design). here, 'templates' means

Re: Templates for application form development

Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 19 Feb 2018, at 12:07, Thomas Beale wrote: > > > note that a key problem I want to address is that templates based on > COMPOSITIONs don't really make sense as

Re: Templates for application form development

Hi, There is NO need for an other RM. Templates (imo) describe an interface. Templates for an interface used for display only need annotations in the appropriate nodes of the Display Archetype Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On

Re: Templates for application form development

Could we have access to that Pablo? Regards Jussara Rotzsch Em dom, 18 de fev de 2018 às 15:58, Pablo Pazos escreveu: > I have a pdf spec in Spanish, this was a university project to have > platform independent GUI definitions based on opts, while creating > technology

repository of AQL queries ?

Hallo, Is there somewhere a repository of archived AQL queries ? I could imagine that to be a bit problematic because the queries are always bound to their corresponding repository of archetypes. An AQL-query-repository would be great as a source for examples when trying to learn AQL. It would

Re: openEHR REST APIs - Release 0.9.0 / invitation for comments

Hi Seref, Thank you very much for your clarifications. So, the SELECT in AQL works like a JOIN in SQL (or like the behavior of Xquery and Sparql with which I am not that much familar yet). This is something that should be better emphasized in the documentation. As you say that many people ask

Re: openEHR REST APIs - Release 0.9.0 / invitation for comments

Hi Georg, Please see comments inline On Fri, Feb 16, 2018 at 5:21 PM, Georg Fette wrote: > Hi Seref, > Quite some discussion you already had on this topic last year. The > examples are a bit hard to grasp because of their complexity in size. > Although they are not