summaryrefslogtreecommitdiff
path: root/server/NOTES
diff options
context:
space:
mode:
Diffstat (limited to 'server/NOTES')
-rw-r--r--server/NOTES173
1 files changed, 168 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. &quot; osv.)