Kuldneloojang

Meeskond ja projekt

• Andrus Seiman
• Marko Belzetski
• Priit Tiganik
  • Kristjan Peterson - ei osalenud arenduses

Lõpptooted:

• Veebiteenus ja klientrakendus: Link antud lehe peatükile
• XML: Link antud lehe peatükile

Retsensioonid meie projektile

Meie tööle kirjutatud retsensioonid

Veebiteenus

Retsenseerija meeskond: Kes soovib retsenseerida?

TODO

Klientrakendus

Retsenseerija meeskond: BeerPressure

retsensioon discussioni lehel

XML

Retsenseerija meeskond: Kes soovib retsenseerida?

TODO

Analüüs

Kirjeldus

Vanadekodu “Kuldne loojang” on vanadekodu nagu vanadekodud ikka. Siin kantakse igapäevast hoolt vanemate inimeste eest, kes üksi enam hakkama ei saa ja kelle eest hooldamise on lähedased inimesed usaldanud professionaalide kätte. Vananevas ühiskonnas on vajadus säärase teenuse vastu suur ja pidevalt kasvav, seetõttu on konkurents tihe. Kuna teenuse kvaliteet on vanadekodule “Kuldne loojang” südameasi, on juhtkond otsustanud investeerida teenuse kvaliteedikontrolli digitaliseerimisse. On tehtud plaan luua infosüsteem, mis aitab põetajatel pidada järge klientidega igapäevaselt sooritatavate protseduuride üle. Kuna infotehnoloogia on juhtkonnale võõras teema, siis on otsustatud alustada vaikselt ja liikuda samm haaval. Seetõttu on disainitav infosüsteem kaunis väike.

Kasutajad

• juhtkonna poolt volitatud administratiivsed kasutajad, kes jagavad kasutajate õiguseid ja kontrollivad põetajate tööd
• vanadekodu arstid, kes teostavad meditsiinilist läbivaatust ja määravad vajalikke protseduure,
• klientide lähedased või kliendid ise, kes pääsevad ligi nendega seotud kliendiga seotud informatsioonile (meditsiiniline läbivaatus, protseduurid, jne.)
• põetajad, kes saavad tutvuda tööülesannetega ning märkida neid teostatuks

Infosüsteemi funktsionaalsus

• Vanadekodu arsti vastutada on klientide tervise jälgimine.
• Vajadusel teeb arst tervisekontrolli käigus ettekirjutisi, mille järgi põetajad klientide eest hoolitsevad.
• Iga ettekirjutise kohta on teada kirjeldus, algus ja lõpu kuupäev ning sagedus, mis ütleb kui tihti protseduure ette tuleb võtta.
• Vanadekodus võib tegutseda korraga mitu arsti.
• Ühele kliendile võib ettekirjutisi teha mitu erinevat arsti.
• Kuna klientide eest hoolitsemine käib kindlate graafikute alusel, siis peab ettekirjutises märgitud protseduuri sagedus tulema lubatud sageduste sõnastikust, mis sisaldab sagedusi nagu “kolm korda päevas peale sööki”, “hommikul ja õhtuti enne sööki”, jne.
• Kui arst on ettekirjutise teinud, siis vastavalt alguse ja lõpukuupäevadele ning valitud sagedusele genereeritakse süsteemi kõik üksikud protseduurid, mis selle ettekirjutuse täitmiseks on vaja teostada.
• Protseduuride läbi viimiseks on vanadekodus põetajad. Põetajate ülesanne on klientide eest hoolitsemine ja arstide ettekirjutuste elluviimine. Kuna patsiente on palju ja ettekirjutused erinevad, siis on vaja olla hoolas. Infosüsteem on selleks, et aidata põetajatel järge pidada, mis tööd on juba tehtud või mis töid on veel vaja teha. Selleks kuvab infosüsteem kõiki ühe toa või ühe kliendi kohta tänasel päeval tehtavaid protseduure.
• Kui protseduur on täide viidud, siis saab põetaja märkida selle tehtuks ja asuda järgmiseid ülesandeid täitma.
• Lähedastel on esialgu infosüsteemis väike roll. Nemad saavad lihtsalt uurida, mis ettekirjutisi arst on nende lähedaste kohta teinud ja kas need on kõik ikka ellu viidud.
• Administraatoritel on voli luua teisi kasutajaid ja jagada neile rolle.
• Lisaks on neil võimalus kontrollida arstide ja põetajate töid ning korraldada klientide paiknemist tubades.

Andmemudel

API endpointide kirjeldus (esialgne)

Tegemist on esialgse, analüüsi käigus loodud kirjeldusega. Lõpliku dokumentatsiooni saamiseks kasuta veebiteenuse Swaggerit.

User

POST/user - Adds a new user

GET/users/{UserId} - Returns a user object for the given UserId

DELETE/users/{UserId} - Deletes the user according to user id

PATCH/users/{UserId} - Modify the user's data

GET/users - Returns all the users in the database

Guardian

POST/guardian - Adds a new patient's guardian

GET/guardians/{GuardianId} - Returns a patient's guardian by ID

DELETE/guardians/{GuardianId} - Deletes guardian according to guardian's ID

PATCH/guardians/{GuardianId} - Updates Guardian according to id

GET/guardians - Returns all Guardians

Patient

POST/patient - Adds a new patient

GET/patient/{PatientId} - Gets patient according to patient ID

DELETE/patient/{PatientId} - Deletes patient according to patient ID

PATCH/patient/{PatientId} - Modified patient's data according to patient ID

GET/patients - Returns all patients

UserType

POST/usertype - Adds a new usertype

GET/usertypes/{UserTypeId} - Returns a usertype object for the given UserTypeId

DELETE/usertypes/{UserTypeId} - Deletes the usertype according to usertype id

PATCH/usertypes/{UserTypeId} - Modify the usertype's data

GET/usertypes - Returns all the usertypes in the database

PatientRoom

POST/patientRoom - Adds a new patientRoom

GET/patientRooms/{PatientRoomId} - Returns a patientRoom object for the given PatientRoomId

DELETE/patientRooms/{PatientRoomId} - Deletes the patientRoom according to patientRoom id

PATCH/patientRooms/{PatientRoomId} - Modify the patientRoom's data

GET/patientRooms - Returns all the patientRooms in the database

Room

POST/room - Adds a new room

GET/rooms/{RoomId} - Returns a room object for the given RoomId

DELETE/rooms/{RoomId} - Deletes the room according to room id

PATCH/rooms/{RoomId} - Modify the room's data

GET/rooms - Returns all the rooms in the database

PatientsDoctor

POST/patientsDoctor - Adds a new patientsDoctor

GET/patientsDoctor/{PatientsDoctorId} - Returns a patientsDoctor object for the given PatientsDoctorId

DELETE/patientsDoctor/{PatientsDoctorId} - Deletes the patientsDoctor according to patientsDoctor id

PATCH/patientsDoctor/{PatientsDoctorId} - Modify the patientsDoctor's data

GET/patientsDoctors - Returns all the patientsDoctors in the database

MedicalReview

POST/medicalReview - Adds a new medicalReview

GET/medicalReviews/{MedicalReviewId} - Returns a medicalReview object for the given MedicalReviewId

DELETE/medicalReviews/{MedicalReviewId} - Deletes the medicalReview according to medicalReview id

PATCH/medicalReviews/{MedicalReviewId} - Modify the medicalReview's data

GET/medicalReviews - Returns all the medicalReviews in the database

GET/medicalReviews/patient/{PatientId} - Gets all medical review IDs for the given patient

FrequencyType

POST/frequencyType - Adds a new frequencyType

GET/frequencyTypes/{FrequencyTypeId} - Returns a frequencyType object for the given FrequencyTypeId

DELETE/frequencyTypes/{FrequencyTypeId} - Deletes the frequencyType according to frequencyType id

PATCH/frequencyTypes/{FrequencyTypeId} - Modify the frequencyType's data

GET/frequencyTypes - Returns all the frequencyTypes in the database

Kasutajalood ehk üldisem kliendi funktsionaalsuse kirjeldus

Kasutajalood-funktsionaalsus erinevatele rollidele. Kasutatud ERD tabelite nimetusi. Nice-to-have funktsionaalsus on märgitud tärniga (*).

Administraator

Soovin

• Lisada/muuta/kustutada tubasid
• Lisada/muuta/kustutada kasutajaid: hooldaja, arst, patsient, kliendi lähedane
• Lisada/muuta/kustutada Patient seost Room-is
• Lisada/muuta/kustutada FrequencyTypesid
• Lisada/muuta/kustutada kõiki muid mõeldavaid asju kõikide tabelitega *

Arst

Soovin

• Patsiendi külge lisada uut MedicalCase-t
• MedicalCase külge lisada Prescription ja määrata selle sagedus
• Saada ülevaadet enda MedicalCase-dest
• Saada ülevaadet enda patsientidest
• Enda ühe Patienti raames ülevaadet
  • tema MedicalCase-dest
  • Prescription-itest
  • Procedure-dest

Patsient või kliendi lähedane

Soovin

• Saada ülevaadet enda kõikidest MedicalCase-dest
• Saada ülevaadet enda Prescription-itest
• Saada ülevaadet enda Procedure-dest
• Saada teada, mis toas ma asun

Hooldaja

Soovin

• Teada, millised Procedure pean järgmisena tegema
• Märkida üks (või mitu korraga*) Procedure tehtuks
• Ülevaadet, milliseid procedure-sid ma pean tegema mingis kuupäevavahemikus*
• Ülevaadet, milliseid procedure-sid ma olen mingis kuupäevavahemikus teinud*

XML ülesande kirjeldus

Kuna antud ülesandega tuli kokku päris palju faile, ei ole hakatud nende sisu siia kopeerima, vaid kõik failid leiab üles sellelt aadressilt: https://drive.google.com/drive/folders/1HzdoZaEJ-i475aFXH-OfYER7Try0fNne

Failide nimekiri:

• KuldneLoojang.wsdl - infoks WCF SOAP teenuse kirjeldus, mille abil näidis-XML ja xsd said loodud
• KuldneLoojang.xsd - XSD fail XML-i sisu kirjeldamiseks
• KuldneLoojangExample_forXML.xml - XML näidis, millesse on lisatud HTML-iks transformeerimise XSLT faili link
• KuldneLoojangExample_forHTML.xml - täpselt sama XML näidis nagu eelmine, aga sellesse on lisatud HTML-iks transformeerimise XSLT faili link
• KuldneLoojang_toHTML.xslt - meie XMList HTMLi transformatisioonid
• KuldneLoojang_toXML.xslt - meie XMList väikese uue XMLi transformatisoonid

XMLi näide pärineb enam-vähem meie veebirakenduse andmestruktuurist, kuigi lihtsuse nimel on seda veidi muudetud, nimelt on guid lühendatud ning käsitsi lisatud mõned attribuudid. XML-ist leiab väikese infohulgaga patsiendid, kellel on omakorda küljes nimekiri temaga seotud haigusjutudest (Medicalcase) ning viimaste küljes võib olla veel hulk raviprotseduure (Prescription). XMLi näidetes on alles jäetud SOAP päised ja nimeruumid. Kuigi need lisavad andmete töötlemisel keerukust, on nimeruumidega tegelemine eluliselt vajalik oskus ja seetõttu ei hakanud neid ka eemaldama ja XMLi lihtsamaks muutma. Kolmele XMLi tasemele on lisatud andmete lisakirjeldusena atribuute.

Järgnevalt veidi lähemalt transformatsioonidest.

KuldneLoojang_toHTML.xslt

Õppejõu poolt antud ülesanne nõudis paljude erinevate XSLT võimaluste kasutamist. Otsustasime erinevaid transformatisoone kasutada erinevate HTML tabelite loomiseks.

Esimeses tabelis on ära toodud Kuldne Loojang hooldekodu kõikide patsientide nimekiri kasutades xsL:for-each meetodit. Lisaks antakse igale reale xsl:choose abil klassi nimetus vastavalt patsiendi soo atribuudile. Nõnda on lõpptulemuses mehed värvitud siniseks ja naised roosaks.

Teises tabelis antakse ülevaade patsientide ravist ning välja on kogutud kõik raviprotseduurid. Nende külge on omakorda otsitud XPath ancestor meetodiga nende protseduuride haiguslood ja patsiendid. Lisaks on andmed patsiendi perekonnanime järgi sorteeritud.

Kolmandas janeljandas tabelis on välja otsitud ilma ravita patsiendid. Neid saab eristada kahte viisi kasutades. Esiteks on haiguslugudel XMLis küljes info, kas neil on küljes raviprotseduure või mitte. Seda lahendust kasutab kolmas tabel. Neljandas tabelis loetakse XSLT abil kokku, mitu raviprotseduuri ravijuhtumil küljes on ning kui neid ei ole, siis kuvatakse patsiendi andmed.

Lõplik transformatsioon näeb meie andmetega välja alljärgnev:

KuldneLoojang_toXML.xslt

Kuna HTMLi transformeerimisel on kasutatud juba teatud hulk nõutust, siis XMLi transformatsioon sai üpris lihtne. Selle tag-ide nimetused on muudetud eestikeelseteks ning kokku on kogutud kõik raviprotseduurid. Lõpptulemus näeb välja alljärgnev:

<?xml version="1.0" encoding="UTF-8"?>
<ettekirjutused>
	<ettekirjutus id="9223d9c2">
		<kirjeldus>võta Sudafedi</kirjeldus>
		<algus>2018-01-01</algus>
		<lopp>2018-01-14</lopp>
	</ettekirjutus>
	<ettekirjutus id="35c813bd">
		<kirjeldus>loputa nina</kirjeldus>
		<algus>2018-02-01</algus>
		<lopp>2018-02-14</lopp>
	</ettekirjutus>
	<ettekirjutus id="d10d3379">
		<kirjeldus>võta rögalahtistit</kirjeldus>
		<algus>2018-03-01</algus>
		<lopp>2018-08-14</lopp>
	</ettekirjutus>
	<ettekirjutus id="220d3379">
		<kirjeldus>võta valuvaigistit</kirjeldus>
		<algus>2017-01-01</algus>
		<lopp>2017-01-14</lopp>
	</ettekirjutus>
</ettekirjutused>

Lõpptoode

Kood / Versioonihaldus

Lõpptoode

https://www.dropbox.com/s/4h9bvq4k6388fmo/loojang.zip?dl=0 (seisuga 02.06.2018, bugide parandusi lisatud 04.06.2018)

Versiooni haldus

Veebirakendus https://bitbucket.org/itcollegeprojects/loojang-app/

Klientrakendus https://bitbucket.org/itcollegeprojects/loojang-client/

Käivitamine (retsensentidele)

Ettevalmistus.

Projekti paigaldamiseks on kaks varianti: 1) kloonida mõlemad repositooriumid või 2) alla laadida .zip fail ning lahti pakkida see sobivasse kohta. Viimasel juhul paigaldatakse nii veebi- kui ka klientrakendus korraga.

Veebirakendus.

Avada Visual Studios LoojangApp solution ning käivitada projekt Web App läbi. Kuna kõik vaated on projektist eemaldatud, siis avaneb tühi aken. Sealt tuleb välja lugeda veebiaadress, mille poole klientrakendus pöörduma peab. Meie puhul oli selleks: https://localhost:44382. On võimalik, et igas süsteemis on see erinev. Sellisel juhul tuleb vastav aadress meelde jätta ning kopeerida see klientrakenduse sätetesse. Vastasel juhul ei oska klient veebirakenduse poole pöörduda.

Klientrakendus.

Peale kloonimist käivitada käsurealt klientrakenduse kaustas käsud projekti ehitamiseks ning käsud käivitamiseks:

npm install (vajalik vaid esimesel korral, sest paigaldab vajalikud paketid)

npm run start-en või npm run start-ee (vastavalt inglise või eesti keelse rakenduse käivitamiseks)

Kui backendi aadress erines meie poolt kasutatavast (https://localhost:44382), siis tuleb otsida klientrakenduse kaustas src/enivornemnts/environments.ts ja src/enivornemnts/environments.prod.ts failis ära muutuja apiUrl väärtused. Selle aadressi pihta teeb klient päringud ja see peab ühtima veebirakenduse aadressiga.

Rakenduses on neli erinevat kasutaja tüüp: admin, doctor (arst), caretaker (hooldaja) ja guardian (lähedane). Nendele on loodud vaikimisi kasutajad vastavalt: admin@eesti.ee, doctor@eesti.ee, caretaker@eesti.ee. guardian@eesti.ee. Kõikide parool on aaaaaa. Kasutajaid võib vabalt juurde teha, kuid uued loodud kasutaja on õigusteta ning neile peab õigused andma mõni olemasoleva admin kasutaja.

Uues andmebaasis esimest korda käivitamisel täidetakse baasis ainult FrequencyTypes tabel, ülejäänud info patsientide, tubade jne kohta tuleb retsensendil ise klientrakendusse sisestada ja asuda seoseid looma. Kuna teiste rollide õigused on muudatuste tegemiseks andmebaasis on piiratud, tuleks alustada andmete sisestamist rollis "admin".

Tegevuste logi

Analüüs ja dokumentatsioon

• 2018-03-06 Meeskonna loomine, teema fikseerimine
• 2018-03-14 Esialgne analüüs ja andmemudel
• 2018-03-16 API kirjeldus Swaggeris
• 2018-03-23 Wiki lehe loomine
• 2018-05-31 XMLi osa täiendamine wikilehel
• 2018-06-01 Veebiteenuse ja klientrakenduse kokkuvõtte lisamine

Veebirakendus

• 2018-03-20 Repositooriumi loomine TFS-is. Mudelite ja DAL-i seadistamine.
• 2018-03-23 Andmebaasi kiht EF baasil püsti.
• 2018-03-30 Analüüsi lõplik vormistamine wikis. Äriloogika arendamise algus.
• 2018-04-10 Kasutajalugude lisamine wikisse. Swaggeri integreerimine koodi.
• 2018-04-13 Identity lisatud veebirakendusele.
• 2018-04-15 Veebirakenduse äriloogika selgroog püsti (Factoryd, DTO-d ja Serviced enamikele olemitele). Algas suurem kontrollerite tegemine.
• 2018-04-28 Enamus CRUD operatsioone ja vastavaid kontrolleried töökorras. Edaspidi arendati palju asju paralleelis kliendiga ning täiendati vastavalt veebiteenuse äriloogikat või kontrollereid.
• 2018-05-06 Logimise lisamine veebirakendusele.
• 2018-05-16 Enamus kontrolleritesse sisseviidud turvakontrollid vastavalt kasutaja rollile või id-le.
• 2018-05-20 Täiendavad turvalisuse nõuded sisse viidud
• 2018-05-30 Koodi puhastamine. Kasutamata kontrollerite ja vaadete eemaldamine.

Klientrakendus

• 2018-04-09 Pandi algus klientrakenduse arendamisele.
• 2018-04-12 Esimene vaade püsti.
• 2018-04-12 i18 mustriga kakskeelsuse toe lisamine.
• 2018-04-17 Rollide põhine roiting.
• 2018-04-22 Baas pipe-d olemite sortimiseks või filtreerimiseks.
• 2018-05-01 JWT tokeniga sisse logimine.
• 2018-05-09 Vaadete lisamine (toad, arstlikud läbivaatused).
• 2018-05-15 Navigation-bari lisamine.
• 2018-05-21 Protseduuride ja nende sageduse lisamine.
• 2018-05-25 Kasutajahaldus.
• 2018-05-29 Tokeni talletamine.

Projektliikmete panus

• 1/3 Andrus Seiman (valdav osa klientrakenduse koodist, andmemudeli ja EF andmebaasikihi loomine, analüüs, wiki)
• 1/3 Marko Belzetski (suurem osa äriloogikast ja kontrolleritest, turvalisuse nõuded ja nende täitmise kontrollimine, analüüs)
• 1/3 Priit Tiganik (suur osa äriloogikast ja kontrolleritest, protseduuride ja ettekirjutuste vaated klientrakenduses, analüüs, XML-osa, wiki)
• Kristjan Peterson loobus üsna algul isiklikel põhjustel. Rakenduste loomises ei osalenud, küll aga panustas analüüsi ja wiki-lehe loomisse.

Meie tehtud retsensioonid

Veebiteenusele

Retsensioon meeskond Curry veebiteenusele link TODO

Klientrakendusele

Retsensioon meeskond Curry klientrakendusele link TODO

Meeskond Curry on loonud klientrakendusena kliendi oma poolt loodud veebiteenusele. Kaks asja koos moodustavad platvormi, mida saab kasutada krüptorahadega kauplemiseks. Platvorm toimib põhimõttele, et igaüks saab tulla ja luua omale konto, kus saab ülevaate oma krüptorahakoti seisust. Testimiseks täidetakse kasutaja rahakott juhuslike arvude generaatori abil erinevate krüptovaluutadega. Kasutajal on võimalik panna üles ordereid meelepäraste valuutapaaride vahel täpsustades soovitud hinna, koguse ja tehingu tüübi (ost või müük). Orderid jäävad seni üles, kuni leidub vastaspool, kes soovib viia läbi vastupidise tehingu. Seepärast on soovitatav rakenduse testimiseks teha kaks kontot, kelle vahel siis tehinguid ellu viia.

Klientrakendus on teostatud Angulari raamistikus. Klientrakendus on kirjutatud veebiteenuse solutioni sisse, mistõttu käib tema käivitamine mugavalt üheskoos veebiteenusega. Klientrakenduse projekti ülesehitus on selge ja arusaadav. Kood on suudetud hoida puhas. Mõned komponendid on siiski päris suured ja võiks ollaväiksemateks osadeks jaotatud. Esineb mõningat koodi kopeerimist, mida oleks võimalik vähendada kirjutades asju komponentidesse. Näiteks tehingute teostamisel on ostu- ja müügitehingu vormid ühesugused, mida oleks lihtsalt saanud hoida ühes komponendis. Rakenduse kasutamise, ega paigaldamise kohta pole mitte mingisugust informatsiooni. Õnneks on talupoja mõistusega rakenduse käivitamine siiski võimalik. Tuli avada vastav solution, luua lokaalne andmebaas ning seejärel käivitada solutionis vastav projekt (WebApp), mis pani korraga käima nii veebiteenuse kui ka klientrakenduse. Järgnevalt mõningaid tähelepanekuid rakenduse kasutamise kohta:

• Kasutaja loomisel valideeritakse kenasti kasutajaandmeid. Pole võimalik sisestada liiga lühikest nime või liiga lihtsat parooli. Kasutaja loomisel antakse kenasti tagasisidet, kui üritatakse luua kasutajat, kelle kasutajanimi või email on juba kasutusel.
• Kasutajal on võimalik muuta kasutajaandmeid - eesnimi, perekonna nimi ning email. Paraku pole võimalik muuta ei parooli ega kasutajanime.
• Klientrakendus näeb selge ja puhas välja. See on saavutatud Bootstrap CSS raamistiku kasutamisega.
• Äriloogika on krüptovaluutade-võõrale kasutajale pisut segane. Kliendi vaatest on näha, et kauplemine on võimalik vaid kahe valuuta suhtes (Bitcoin ja Ethereum). See tähendab, et üks kahest peab olema alati valitud. Seejärel saab kasutaja valida, mis valuuta on tehingu vastaspooleks. See tähendab, et kui näiteks soovitakse vahetada Monero valuuta Agrello vastu, siis tuleb kõige pealt Monero vahetada Ethereumi vastu, mis seejärel vahetatakse Bitcoini vastu, mille eest lõpuks saab osta Agrello valuutat.
• Huvitaval kombel saab kasutaja olla iseenda tehingu vastaspooleks. See tähendab, et kui kasutaja on pannud üles orderi ostmiseks ja seejärel ka müümiseks, siis ka selline tehing läbi viiakse.
• Klientrakenduses on puudu loogilisi funktsionaalsuseid, mis võiks olla seda sorti platvormil realiseeritud. Näiteks kasutajana sooviksin näha enda poolt läbiviidud tehingute ajalugu või sooviksin tühistada enda poolt üles pandud orderieid, jne.
• Kliendipoolelt paistab välja üks äriloogika viga. Näiteks kasutaja krüptovaluutade bilanss ei muutu nii nagu eeldaks. Viies läbi müügi tehingu, kus hind on 10 ja kogus 5, siis müüdava valuuta kogus väheneb vaid 5 võrra, mitte 50 võrra nagu oleks eeldanud. Seda kas selle vea põhjustab kliendi või rakenduse pool peaks välja selgitama koodi põhjalikum analüüs.
  • Selliseid vigu, mis suudaksid klientrakenduse kokkujooksutada või panna ta andma veateatei, ei suudetud leida.

Kokkuvõtvalt võib öelda, et meeskond Curry on näidanud, et oskavad klientrakendust luua ning saavad aru kuidas klientrakendus peab suhtlema veebiteenusega. Puudused, mis saab välja tuua pole tehnilist laadi vaid pigem seotud sellega, et klientrakenduse poolele on realiseeritud skoop väiksem, kui võiks antud rakendusest eeldada.

XML-ile

Retsensioon meeskond Curry XML-ile link