diff options
Diffstat (limited to 'server/NOTES')
| -rw-r--r-- | server/NOTES | 147 |
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? + |