Meeskond Tudengikalender:XML retsensioon Poial

XML osa retsensioon meeskonnale Pöial

• Lisatud: 16.03.2014
• Taavi Sildeberg
• Kunnar Kukk

Retsenseeritav materjal: https://wiki.itcollege.ee/index.php/Poial

XML-fail

Tegemist on veebipoe andmefailiga, milles hoitakse sees infot kaupade, nende koguste, suuruste, hinna jm kohta. Nagu me ka teises arvustuses ütleme, on stiililt tegemist suurtähtede puhul küsimusega, kas see muudab koodi loetavamaks või mitte. Erinevalt meeskonnast RAKK (keda me arvustasime), on siinkohal xml-fail kirjeldatud eestikeelsena.

Faili struktuur ja ülesehitus on mõistetav ning loogilised. Faili päises on kirjeldatud kodeering ning xml versioon.

Element Suurus, hoitakse kahte tüüpi väärtused. Samaväärselt kasutatakse nii string tüüpi (nt Bätmani pükste juures) M ning arvulist tüüpi 36 (Klassikaline pruun naiste saabas). Sealjuures Xsd failis on määratletud see element string tüüpi muutujana. Ehk, ei ole täpsustatud elemendi atribuudiga, kas tegemist on stringi või tähelise väärtusega (näiteks võib tekkida olukord, kus ka triiksärk on antud arvulise suurusega 52 mitte L või teisendamisel kasutada täpset suurust, kuna tähelised suurused on arvuliselt ordinaaltunnused). Soovitus on elemendi juures kasutada atribuuti, mis näiteks särkide puhul välistaks taolise olukorra, kus osad särgid on numbrilise suurusega, teised tähemärke kasutavate suurustega. Jalanõude puhul muudab praegune olukord keerulisemaks näiteks suuruste järgi järjestamise.

Failis esineb mõningaid iluvigu veel. Näiteks on kategoriseeritud toode ID=3 Liik=“Jope“, kuigi üleval on kirjeldatud Liiki Joped. Miskipärast esineb korduvalt elemendi Hind atribuut Ühik=“ EUR“. Kui see on pandud eesmärgiga hiljem vältida tühiku kirjeldamist HTML-koodis, siis tundub see ebaotstarbekas ning disaini ja andmekihi loogikate segiajamine. Kui see on kogemata tehtud, siis tuleks see parandada. Segi on faili ülaosas aetud ka elemendi Kontakt atribuutide Telefon ja Email väärtused. Telefoniks on e-mail ja vastupidi.

Kokkuhoidlikum käsitlus XML-st oleksime toodete puhul kasutanud lähenemist, et võimalikult palju infot kirjeldanud atribuutides, mis praegu on eraldi elemendid. Praegune lähenemine

<Toode ID="1" Kogus="11" Kategooria="Mehed" Liik="Püksid">
      <Nimi>Batmani püksid</Nimi>
      <Bränd>Batman</Bränd>
      <Pilt>http://enos.itcollege.ee/~smaeots/Vorgu2/Pildid/batmani_pyksid.jpg</Pilt>
      <Suurus>M</Suurus>
      <Hind Ühik=" EUR">55</Hind>
      <Kirjeldus>Mugavad ja vastupidavad!</Kirjeldus>
 </Toode>

Kokkuhoidlikum oleks sama andmestruktuuri juures ilma loetavuse kaota olnud koondada alamelemente ja kasutada atribuute:

<Toode ID="1" Kogus="11" Kategooria="Mehed" Liik="Püksid">
	<Bränd nimi=“Batman“ mudel=“Batmani püksid“/>
	<Pilt src=“URL“/> 
	<Kirjeldus suurus=“M“ hind=“55“ ühik=“EUR“>
		Mugavad ja vastupidavad!
	</Kirjeldus>
 </Toode>

XSD-fail

XSD-faili üldmulje on, et tuleks korra veel läbi mõelda väärtused ning võimalikud vead, mis võivad tekkida.

Tüübikirjeldused Liik ja Kategooria kasutaksime piiranguid väärtustele, kuna omistatavaid väärtuseid ühel juhul on 2 ja teisel 5. Seda saaks teha järgnevalt:

<xs:simpleType name="Kategooriad">
   <xs:restriction base="xs:string">
     <xs:enumeration value="Mehed"/>
     <xs:enumeration value="Naised"/>
   </xs:restriction>
 </xs:simpleType>

See välistab võimaluse, et väärtused oleksid midagi muud. Sama saab teha suuruste juures. Materjali selle võimaluse kohta leiab http://www.w3schools.com/schema/schema_facets.asp

Tüübikirjelduses, mis kirjeldavad elemente Kontakt, on kasutatud tüübina xs:string, selle asemel, et määrata Type=“emailAddress“ ning Type=“mobileNumber“. Praegusel juhul annab XSD võimaluse kirjutada vigase e-mailiaadressi või telefoninumbri. Samuti võimaldab element minna täpsemaks ning piirata regulaaravaldisega telefoni või e-maili kuju. Vastavat materjali pakub näiteks Stackoverflow.

Huvitav on ka väärtus unsignedByte kaupade hinna kirjelduse juures. See tähendab, et 256 eurot maksvaid saapaid või kleite selles poes ei müüda ning kauplus piirdub väärtustega 0..255. Samas, tasuks jätta ruumi kallimate jopede ja kleitide jaoks ja kasutaksime ise antud juhul unsignedShort. Või, kui on vaja komadega hindu väljastada, siis decimal. Samamoodi, nagu eelviidatud, võiks kasutada piiranguid ja määrata minimaalne väärtus ning maksimaalne väärtus. Elemendi Kogus puhul on unsignedByte kasutamine mõistetav, kuna e-poe ladu tõenäoliselt pole väga suur.

XSLT-fail

Praegusel juhul on loodud üks transformatsioonifail, kuigi ülesande püstituses oli neid 2 tükki vajalik ehitada.

Selle osa juhataksime sisse katkendiga Aapo Ilvese luuletusest „Vihmavari“ (ärgu retsenseeritavad solvugu) http://luuleleid.wordpress.com/2010/10/08/aapo-ilves-vihmavari/:

suitseta joo viina armu ning tüsene sul on istuv töö

otsusta ära mõtle ümber tee uuesti paremini veel paremini

Tegemist on HTML väljundiga, mida kirjeldatud ei ole. Koodi lugedes võib oletada, et loojate eesmärk on olnud väljutada tooted ID-järgi.

Päis on kirjeldatud ning on antud koodi tulemus. Segamini on stiil (CSS), mis on paigutatud HTML-elementide style atribuudi sisse ning XSL. Stiilide osas võinuks eraldada siiski stiili ja koodi ning kasutada klasse. XSL-arhitektuur on raskemini seetõttu jälgitav. Samas on see lubatud kasutus.

Kood siiski töötab ning annab tulemuse, kuid ilus oleks pidada kinni standardsema HTML-koodi kirjutamisest ning pigem vähem elemente väljutada kui rohkem.

Kokkuvõte

Soovitame kindlasti üle vaadata XML fail, arvestada soovitusi ning XSD skeem ja luua ka teine transformatsioon. Skeemifailis piirata väärtuseid, mõelda korraks läbi hinna puhul, kas oleks targem kasutada komadega arve ning piirata tüüpidega mobiilinumber ja e-mail. XSL-i puhul kindlasti kirjutada ilusam HTML ning soovitame koodi kommenteerida. Retsenseerima hakates tuleb kõigepealt süveneda koodi, et aru saada, mis on olnud eesmärk.