diff options
| -rw-r--r-- | server/NOTES | 173 | ||||
| -rw-r--r-- | server/TODO | 14 |
2 files changed, 182 insertions, 5 deletions
diff --git a/server/NOTES b/server/NOTES index 8cfaca8..8e99a1d 100644 --- a/server/NOTES +++ b/server/NOTES @@ -1,15 +1,178 @@ +################### +# Makro templates # +################### +En makro template består af tre dele: + 1: Header + 2: Queries + 3: Widgets + +Headeren indeholder alle overordnede info, såsom cpr nummer og makro + version. + +Queries udføres af serveren een gang og resultaterne mappes til nogle + symboler som kan bruges i value felterne i widgets sektionen. + +Der skal være mulighed for simpel aritmetik i mapningsfunktionerne. + +Widgets sektionen er som beskrevet andetsteds. + +########### +# Queries # +########### +For at en query skal give mening, skal der være en stor mængde klasser + man kan lave requests på. + Disse klasser skal tilsammen beskive al apparatur på afdelingen, + hiraktisk, så man f.eks kan bede om "lensmeter" eller en konkret + model. + +En nedarvningsmodel kan bruges som inspirationskilde. + +Der skal være mulighed for at hæfte flere klasser på det samme + apparat, idet nogle apparater måler mere end een ting. (ala multipel + nedarvning.) + +Sproget i en query som laver mapningen. + -> class, cpr, timestamp (oldest) + <- xml formateret + +<svar> + <gruppe navn="fisk"> + <værdi navn="dims" value="42"/> + <værdi navn="fnuller" value="blah"/> + </gruppe> + <gruppe navn="ostemad"> + <værdi navn="dims" value="42"/> + <gruppe navn="olm"> + <værdi navn="fnuller" value="blah"/> + </gruppe> + </gruppe> +</svar> + +Mapningerne kan således laves 1:1 fisk.dims, fisk.fnuller, +ostemad.dims og ostemad.olm.fnuller. + +Eksempler på mapninger: +<map name="myvalue"> + 2*fisk.dims +</map> +<map name="anothervalue"> + pi = 3.14 + sin(fisk.dims / pi) + 42 +</map> + +Mapningssproget + LUA? + Simplere (ala bc)? + + +###################################### +# Preudfyldning af felter i en makro # +###################################### + +Preudfyldningen skal ske serverside. + +Det skal indikeres i feltet at det er preudfyldt og den information + skal lagres sammen med dataene naar de senere bliver gemt paa serveren + efter en commit. + +Hvis preudfyldte felter aendres paa klienten, skal dette indikeres i + de lagrede data. + +Skal den preudfyldte vaerdi lagres, saa man altid kan se hvad det + foreslaaede var? + +Data som allerede eksisterer paa serveren: + Hvis et felt allerede findes paa serveren fra en tidligere + indtastning og dens ttl ikke er overskredet, skal feltet preudfyldes + med denne vaerdi. + + TTLerne? + Hvem skal saette dem? + Hvor skal de saettes? + + Hvis de saettes paa feltet paa kontruktionstidspunktet, uafhangig af + kilden, betyder det at feltet har samme udloebstid uanset om det er + manuelt indtastet, eller indlaest fra en ekstern kilde. + + Et felts ttl vil nok vaere defineret uafhaengigt af kilden, saa + ovenstaeende loesning kan sikkert vaere fin nok. + +Data som kommer fra eksterne kilder: + Et flest skal have en eller flere properties som indikerer at feltet + skal udfyldes fra en ekstern datakilde. + + Disse properties skal beskrive hvilken kilde dataene skal hentes fra, + samt hvor gamle dataene maksimalt maa vaere. + + En maade at goere det paa kunne vaere at kalde en ekstern applikation + (via. popen eller lign.) som spytter data ud paa stdout i et af + pracro velkendt format. + Parametrene til dette eksterne program kan saa styres vha. af en + lignende mekanisme som i formatet til journal resumeet ($$, ${cpr}, + ${firstname}, etc). + + En anden maade at goere det paa kunne vaere at lave et indbygget + kommandosaet som kan tage en raa streng som parameter, som derved + fungerer som kald til et eksternt program, bortset fra at der kaldes + en intern rutine istedet. + + En tredie maade, som er en afart af den anden maade, vil vaere at + lave kommandsaet baseret udelukkende paa kilde. [kilde]/[apparat]/[parameter] + ex. pentominos/lensmeter/axis + Problem: Hvordan skelnes mellem flere ensnavngivne parametre? + I lensmeter findes axis parameteren principielt to gange, een gang + for hoejre og een gang for venstre linse. + +Hvis der baade eksisterer data paa serveren og findes ekstern data. + Dataene paa serveren har precedens over data fra eksterne kilder, + hvis: + a) Dataene paa serveren er nyere end dem fra den eksterne kilde. + b) Dataene paa serveren er indtastet af en bruger og stadig gyldige. + + Hvis der hverken findes gyldig data (ikke eksisterende eller + udloebet) paa serveren eller fra den eksterne kilde (igen ikke + eksisterende eller udloebet) benyttes value feltets indhold. + +Pentominos data eksempel: + Serveren laeser: + <lineedit name="dioptri_odex" + source="pentominos/lensmeter" + command="cliclient --cpr=${cpr} query --filter=latest --deviceid=lensmeter --devicetype=lensmeter --format=xml" + ttl="86400" + value=""/> + + Serveren oversaetter dette til: + <lineedit name="dioptri_odex" + value="4" + source="pentominos/lensmeter"/> + +Taenkt eksempel med et fundus billede: + Serveren laeser: + <image name="dioptri_odex" + source="pentominos/fundus" + command="cliclient --cpr=${cpr} query --filter=latest --devicetype=fundus --format=raw" + ttl="86400" + value="SOMERAWJPEGCODEINBASE64-9823fasd73487234fas7asd8732487asd8fc7sd8f76328732"/> + + Serveren oversaetter dette til: + <image name="dioptri_odex" + value="SOMERAWJPEGCODEINBASE64-9823fasd73487234fas7asd8732487asd8fc7sd8f76328732" + source="pentominos/lensmeter"/> + + ################################### # Avanceret validering af widgets # ################################### LUA Ide: - LUA som validering, sat i serie med en regexp validering. Begge kan vaere - tomme, eller udeladt (svarende til tomme). + LUA som validering, sat i serie med en regexp validering. Begge kan + vaere tomme, eller udeladt (svarende til tomme). - Hver widget optraeder automatisk som preloaded variabel i lua programmet. + Hver widget optraeder automatisk som preloaded variabel i lua + programmet. - Programmet indeholder en funktion validate som returnerer true eller false - afhaengigt af om den er valid eller ej. + Programmet indeholder en funktion validate som returnerer true eller + false afhaengigt af om den er valid eller ej. Hvad med reserverede karaterer i hhv. LUA og XML? skal lua koden base64 enkodes? Eller maaske bare XML kodes (i.e. " osv.) diff --git a/server/TODO b/server/TODO index a8e84f6..042b000 100644 --- a/server/TODO +++ b/server/TODO @@ -1,2 +1,16 @@ +prefetch field + + A 'prefetch' attribute on a field makes the server look up the value on the + pentominos server, using the current patient id, the prefetch field as the + raw request. The latest returned value is the only one used. + A prefetch field overrides the value field. + If a prefetch fails due to no data available, the value field is used. + + + Things to think about: - What to do with resumes in included macroes. Append/prepend to main resume? + - How to integrate fetched values (eg. from Pentominos) and how to store where + the values came from (device/usertyped) + - Can connection keep alive be used for anything useful? Session? State? + - What to do about commits on nondata macroes? (eg. start)
\ No newline at end of file |