Added the file. It contains a lot of thoughts about the design of the system.

1 files changed, 147 insertions, 0 deletions

diff --git a/server/NOTES b/server/NOTES
new file mode 100644
index 0000000..8cfaca8
--- /dev/null
+++ b/server/NOTES
@@ -0,0 +1,147 @@
+###################################
+# 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).
+
+  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.
+
+  Hvad med reserverede karaterer i hhv. LUA og XML? skal lua koden base64 enkodes?
+   Eller maaske bare XML kodes (i.e. " osv.)
+
+  Hvornaar skal koden udfoeres? Naar feltet aendres? Naar feltet forlades (lost
+   focus) eller inden makroen comittes?
+
+  Flere funktioner kan introduceres for at kunne udfoere lua kode paa forskellige
+   tidspunkter (onfocus(), onfocusleave(), onchange(), beforecommit(), etc...)
+
+  Istedet for at bruge direkte mapninger mellem variable og widgets kan man bruge
+   et array (eller hvad der nu svarer til map< std::string, std::string > i c++),
+   saa man slipper for at overskrive nogen af LUAs interne variable og funktioner.
+   Hvis der ikke findes en saadan type i LUA kan man lave et funktionkald ind i c
+   koden som goer det, altsaa field('varname')
+
+  Injicering af data i makroen paa runtime.
+   Et funktionskald fra lua programmet saetter vaerdien af et felt.
+
+  En serie af funktioner kan introduceres til at kontrollere GUI igennem LUA.
+   Funktioner som disable('button1'), uncheck('checkbox2'), osv.
+   Disse funktioner skal bruges til at lave selve makroindholdet dynamisk, saa man
+   f.eks vaelger en radiobutton som aktiverer en hel undersektion af lineedits.
+   Alt dette kan muligvis implementeres vha. checkbox/radiobutton grupper istedte,
+   saa man slipper for denne forholdsvis dybe kontrol paa LUA niveau (laes, der er
+   mange muligheder for fejl!)
+
+Eksempel:
+<lineedit name="dioptri_odex"
+          regexp="[1-9][0-9]{0,2}"
+          lua="function validate() return math.abs(fields['dioptri_odex'] - fields['dioptri_osin']) < 3 end"
+          value=""
+          help="Dioptrien på venstre øje skal være max 2 dioptri fra højre."/>
+<lineedit name="diotri_osin"
+          regexp="[1-9][0-9]{0,2}"
+          lua="function validate() return math.abs(fields['dioptri_odex'] - fields['dioptri_osin']) < 3 end"
+          value=""
+          help="Dioptrien på højre øje skal være max 2 dioptri fra venstre."/>
+
+##################################
+# Forløb og deres struktur i xml #
+##################################
+
+Makro er en del af et forløb
+
+Forløb skal sammensætte makroer i logiske sekvenser.
+ - Backward dependancy
+ - Forward dependancy
+ - Optional
+ - Required
+
+Et forløb beskrevet som et komplet xmldokument?
+ - Alle makroer er indeholdt i et større dokument, forløbet.
+ - Når data postes, lagres forløbs id sammen med makro id'et.
+ - Der er indbygget i xml strukturen en logisk sammenhæng mellem makroerne
+   (dependencies o. lign.).
+ 
+Eksempel:
+<forløb>
+  <makro navn="makro1" completed="true" optional>
+    ...
+  </makro>
+  <makro navn="makro2" depencies="makro1" required>
+    ...
+  </makro>
+  <makro navn="makro3" depencies="makro2" optional>
+    ...
+  </makro>
+  <makro navn="makro4" optional>
+    ...
+  </makro>
+  <makro navn="makro5" optional>
+    ...
+  </makro>
+  <makro navn="makro6" depencies="makro1,makro5" required>
+    ...
+  </makro>
+</forløb>
+
+Eksempel med B2 forloebet i pseudokode:
+B2 req
+
+B21 dep=B2 opt
+
+B22 - B26, B28 dep=B2,B21 opt
+
+B27 dep=B2,B21 req
+
+B29 dep=B27 req
+
+#############################################
+# CPR indtastning, hvordan? hvor? hvornaar? #
+#############################################
+
+ 1) - CPR nummeret hentes fra sygesikringsbevis eller RFID eller lign.
+    - Det sendes til cpr server (ligesom paa barcode)
+    - Naar et apparat skal sende data henter det foerst cpr nummeret vha.
+      sit lokationnummer.
+
+ 2) - CPR nummeret hentes fra sygesikringsbevis eller RFID eller lign.
+    - Det sendes til pentominos med lokationsnummer som raa data som alle
+      andre apparater.
+    - Naar der sendes data fra et andet apparat vedhaeftes kun lokationkoden,
+      og det er pentominos serverens ansvar at vide hvilket cpr nummer der
+      skal bruges.
+ 
+ 3) - CPR nummeret hentes fra sygesikringsbevis eller RFID eller lign.
+    - Nummeret lagres lokalt paa den Soekris kassen.
+    - Naar der sendes apparatdata vedhaeftes det lagrede cpr nummer.
+
+ 4) - CPR nummeret hentes fra sygesikringsbevis eller RFID eller lign.
+    - Nummeret sendes til en server sammen med et lokationsnummer.
+    - Serveren har registreret hvilkemaskiner der findes paa den lokation
+      og broadcatser cpr nummeret til disse.
+
+ 5) - CPR nummeret hentes fra sygesikringsbevis eller RFID eller lign.
+    - Det sendes til cpr server (ligesom paa barcode)
+    - Naar der sendes data fra et andet apparat vedhaeftes kun lokationkoden.
+    - Pentominos serveren henter cpr nummeret fra cpr serveren vha. den
+      vedhaeftede lokationskode.
+
+Overvejelser:
+ a - Data og kilde (cpr nummer) boer holdes samlet.
+ b - Hvem har ansvaret for at cpr nummer og data haenger sammen.
+ c - Hvem har ansvaret for at cpr nummer og data er rigtige?
+ d - Fordele/ulemper ved at have een cpr indtastningsmekaniske pr. Soekris
+     boks.
+ e - Hvilken vej koerer forbindelserne? Kan de fungere igennem en firewall?
+ f - Hvor mange forbindelser er der?
+ g - Boer forbindelserne holdes i live fremfor at lave nye hver gang der
+     skal kommunikeres?
+ h - Hvilke muligheder vil vi have for central logning af hvor patienter
+     bliver 'logget ind'?
+ i - Hvor og hvordan skal cpr numrenes ttl implementeres?
+