summaryrefslogtreecommitdiff
path: root/server/NOTES
diff options
context:
space:
mode:
Diffstat (limited to 'server/NOTES')
-rw-r--r--server/NOTES147
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?
+