In hoofdstuk twee (WML) en hoofdstuk drie (WMLScript) zijn de twee belangrijkste bouwstenen om zelf applicaties te bouwen aan bod gekomen. Samen met de praktische tips uit hoofdstuk vier en de bespreking van de ontwikkelomgeving vormt dit alles een ideaal startpunt om zelf applicaties te ontwikkelen. En dat is dan ook de opzet van dit hoofdstuk.
Stap voor stap wordt een nieuwe applicatie gebouwd, waarbij elke stap volledig uitgelegd is. Ook de principes en tips die doorheen de tekst werden vermeld, worden in de praktijk omgezet. De lezer kan dus zien hoe alle bouwstenen die voorheen zijn aangebracht ook in de praktijk omgezet worden, en samengevoegd tot een functioneel geheel.
De applicatie die ontworpen wordt, noemt e-Search wat staat voor EHSAL-Search. De applicatie laat studenten toe om via het gebruik van een GSM het lesrooster interactief te raadplegen. Een plotse wijziging in het collegerooster kan zo heel snel opgevraagd worden.
De opzet van de applicatie is als volgt: op basis van drie parameters (dag, cyclus en les) kan de student steeds het college selecteren dat op dat ogenblik plaatsvindt. Voor alle duidelijkheid geven we hier de exacte omschrijving van de drie parameters:
De applicatie werd gebaseerd op het collegerooster van een student Handelsingenieur uit het laatste jaar. Het collegerooster (dat geldig was tijdens het academiejaar 1999-2000) kan de lezer op de volgende bladzijde vinden.
Ter illustratie twee voorbeelden, waarbij de drie parameters weergegeven worden:
Ik vermeld hier wel graag bij dat het lesrooster complexer kan zijn, wanneer met even en oneven weken rekening wordt gehouden, of wanneer de student een samengesteld collegerooster zou hebben uit meerdere jaren. Door gebruik van dit “eenvoudig” collegerooster wil ik zeker geen afbreuk doen aan de mogelijke complexiteit ervan.
Desalniettemin wil ik erop wijzen dat het feit of het lesrooster al dan niet complex is, geen enkel belang heeft voor de ontwikkelde applicatie. Zoals meteen zal blijken, wordt de procedurele logica verricht in het script dat achter de applicatie schuilt. Maar die scripttaal is een gewone programmeertaal. Daarom is bewust gekozen voor een eenvoudig lesrooster, omdat het modelleren daarvan in een scripttaal geen extra waarde geeft aan dit werk, maar enkel gebruikt wordt als illustratie van het gebruik van scripts om de applicaties interactiever te maken.
De applicatie bestaat uit twee componenten: de declaratie van de applicatie zelf, en de procedurele logica die erachter steekt. Beide componenten worden in de paragrafen 6.4 tot en met 6.7 uitvoerig toegelicht. Daarnaast wordt ook gebruik gemaakt van een aantal extra elementen, met name figuren, die ik graag ook even toelicht, met het oog op de speciale aandacht die men aan gebruikte figuren dient te geven.
Een overzicht van de gebruikte figuren vindt de lezer hieronder, met de karakteristieken van de afbeelding: het oorspronkelijke bronbestandstype, de breedte en de hoogte, evenals de naam en de grootte in bytes. Deze karakteristieken zijn uiterst belangrijk wil men bij het ontwikkelen van een applicatie gebruik gaan maken van afbeeldingen.
De afbeeldingen zijn trouwens ook van een bijzonder type, dat speciaal voor gebruik bij mobiele terminals werd gecreëerd: het type is de Wireless Bitmap, vandaar de extensie wbmp.
Afbeelding | Bron | Breedte | Hoogte | Naam | Grootte |
---|---|---|---|---|---|
Figuur 27: het EHSAL logo |
BMP | 38 pixels | 48 pixels | logo.wbmp |
228 bytes |
Figuur 28: het e-Search logo |
BMP | 96 pixels | 34 pixels | esearch.wbmp |
408 bytes |
Figuur 29: het info-icoon |
BMP | 85 pixels | 35 pixels | email.wbmp |
318 bytes |
Deze paragraaf legt de opbouw van de applicatie bloot. De volledige broncode kan de lezer vinden in paragraaf 6.7.
Er werd geopteerd om, voor extra duidelijkheid, de code stapsgewijs te ontleden en de bespreking daar meteen onder op te nemen, om zo efficiënt de verschillende gebruikte elementen toe te lichten. Alle elementen werden theoretisch behandeld in de voorgaande hoofdstukken.
Volgende pagina toont het eerste stuk code van het WML-deck.
<?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml>
Deze ophef van code komt bekend voor. Het is een stukje code waarmee een applicatie altijd begint vermits het de declaratie is van het documenttype. We specificeren hierin dat het gaat om een document van het type
XML
, en duiden zo de tekenset aan die wordt gebruikt. Alle elementen die we het deck zullen gebruiken, zitten vervat tussen de starttag <WML>
en de eindtag </WML>
die helemaal op het einde van de code zal staan. (zie paragraaf 2.3.2.2).
De applicatie maakt gebruik van vijf cards die in het deck vervat zitten. We bespreken ze één voor één. Ter herinnering vermelden we hier dat alle elementen die behoren tot één card steeds tussen de tags <card>
en </card>
staan.
<card id="card1" ontimer="#card2"> <timer value="20"/> <p align="center"> <img src="logo.wbmp" alt="logo"/> </p> </card>
Dit is dus de declaratie van de eerste card. De starttag kan dus,
zoals gezegd verschillende attributen bevatten. Deze starttag
<card>
bevat twee attributen die deze kaart
specificeren: een id die aan de kaart een unieke naam binnen het
deck toekent (nodig voor navigatiedoeleinden) en een timer. Dit
ontimer element betekent dat wanneer de waarde van de timer
afgelopen is, er automatisch naar de card met de naam card2
wordt genavigeerd. Er kan ook een title-attribuut gespecificeerd
worden, maar vermits deze card enkel het EHSAL-logo toont, en
geen navigatie voorziet, wordt ze weggelaten. Een header zou het
artistiek aspect verminderen.
Het werken met de timer is een handige tip om het werk voor de gebruiker tot een minimum te beperken. Zoals in de tweede regel staat, wordt de timer ingesteld op twintig seconden. Wanneer de twintig seconden zijn verstreken, wordt dus automatisch, zonder tussenkomst van de gebruiker, overgegaan naar de volgende card.
Tenslotte moet ook de inhoud van de card bepaald worden. Dit gebeurt tussen de tags <p>
en </p>
.
Op te merken valt dat we wensen dat de inhoud wordt gecentreerd, door het toekennen van de waarde
center
aan het attribuut align
van de paragraaf-tag.
We tonen vervolgens een figuur op het scherm met het
img
element. De benodigde attributen hier zijn de bron
(waar is het bestand te vinden) en een beschrijving van de figuur in het
alt
-attribuut. Dit is de tekst die verschijnt als
de figuur door bepaalde omstandigheden niet beschikbaar zou zijn,
of als de tijd voor het laden lang duurt.
Het betreft in feite een principe dat analoog is bij het gebruik van webpagina’s.
De card wordt tenslotte afgesloten door de eindtag
</card>
. Zo kunnen we dus zien dat de declaratie
van de eerste card is voltooid. Merk op dat voor het attribuut
src
(source) van het image
-element een
lokale figuur werd meegegeven. Dat kan zonder probleem ook
een bestand zijn dat ergens anders staat. Wat telt is dat de
juiste referentie wordt meegegeven in het attribuut.
Kortom: deze card toont de gebruiker gedurende twintig seconden het logo van EHSAL en navigeert dan automatisch naar de volgende card. De schermuitvoer van deze card is als volgt:
De lezer kan via de bovenstaande carddeclaratie dus zien dat
binnen een deck de verschillende cards omsloten zitten
tussen de tags <wml>
en
</wml>
en dat binnen een card de tags
<card>
en </card>
de verschillende card-elementen omsluiten.
Dit is een goed voorbeeld van de theoretische beschrijving die in hoofdstuk drie werd geschetst om het concept van WML duidelijk te maken. En meteen ook zal de lezer, die enige ervaring heeft met HTML, de analogie vast en zeker onderkennen.
De code voor de tweede card uit het deck staat in het kader op volgende pagina. Ze is een kleine uitbreiding op de eerste card, en heeft precies dezelfde functionaliteit.
<card id="card2" ontimer="#card3"> <timer value="30"/> <p align="center"> <img src="esearch.wbmp" alt="e-search"/> </p> <p align="center"> Welcome to E-Search! </p> </card>
Deze declaratie van de tweede card is dus analoog met de voorgaande. Ook hier wordt met een timer gedurende 30 seconden een card getoond. Het verschil hier is dat de card niet alleen een figuur bevat in een paragraaf, maar ook een stukje tekst dat daaronder in een afzonderlijk paragraafje is gedeclareerd. Ook hier is het zo dat wanneer de timer is verstreken, er automatisch wordt genavigeerd naar card3.
Het kardinaalteken voor de naam van de card duidt erop dat naar een card wordt genavigeerd die zich binnen hetzelfde deck bevindt. Indien aan een card uit een ander deck wordt gerefereerd, moet de referentie van het deck voor het kardinaalteken opgenomen worden. Onderstaande voorbeelden tonen wat wordt bedoeld:
De tweede card geeft volgend resultaat op het scherm:
De declaratie van de volgende card is het leeuwendeel van de applicatie. Daarom is deze voor de duidelijkheid in twee geknipt.
<card id="card3" > <p> Day: <select name="day" title="Day"> <option value="MON">Monday</option> <option value="TUE">Tuesday</option> <option value="WED">Wednesday</option> <option value="THU">Thursday</option> <option value="FRI">Friday</option> </select> Cycle: <select name="cycle" title="Cycle"> <option value="MO">Morning</option> <option value="AF">Afternoon</option> <option value="EV">Evening</option> </select> Course: <select name="course" title="Course"> <option value="F">First</option> <option value="S">Second</option> </select> <br/>=><u><b>$(assignment)</b></u>
We zien dat deze carddeclaratie enkel één attribuut heeft, en dat is het id attribuut dat de naam van de card specificeert. Het is dan ook een verplicht attribuut, wat bijvoorbeeld niet geldt voor het timer element dat we zonet hebben besproken. Vermits het hier om de hoofdpagina gaat, werd ook geen title-attribuut voorzien. Binnen de paragraaf in de card zien we dat er drie elementen worden gecreëerd waar de gebruiker een keuze zal moeten maken. Omdat alle elementen een zelfde declaratie hebben, wordt enkel deze van de variabele day volledig besproken.
De bedoeling is dat de gebruiker in het scherm, conform onze doelstelling van de e-Search applicatie, drie variabelen kan invoeren op basis waarvan de applicatie aangeeft welk college de student geacht wordt te volgen. De eerste daarvan was de dag. De lezer kan zich hiervoor concentreren op het deel van de code dat schuinsgedrukt staat.
Vooreerst wordt de boodschap Day op het scherm getoond, en
vervolgens krijgt men hiernaast een keuzelijst met mogelijke waarden
die door de gebruiker kunnen geselecteerd worden. Die selectie
gebeurt met het select
-element dat de volgende attributen vereist:
Eenmaal als de variabele, waarin de gebruiker de geselecteerde waarde kan stoppen voor later gebruik in de applicatie, is gedeclareerd, kunnen waarden in de keuzelijst gestopt worden. Want de gebruiker zal nu, indien er geopteerd wordt om de dag te selecteren, een lijst zien met mogelijke waarden waaruit kan gekozen worden. In die optiek verwijs ik graag nog even naar de sterkte van dit element: door gebruik van het select-element kan men vermijden dat nog validatie van gebruikersinvoer dient te gebeuren. Immers, als we al op voorhand alle mogelijk en aanvaardbare waarden voorzien, weten we zeker dat er geen foute waarden ingegeven kunnen worden door de gebruiker.
In e-Search worden voor de keuze van de dag vijf mogelijke waarden voorzien. Elke mogelijke waarde is een option value, waarvan de lezer de declaratie kan volgen op de code. De lezer ziet duidelijk dat er vijf mogelijkheden zijn. We lichten één keuzemogelijkheid toe:
Voorbeeld: <option value="MON"> Monday </option>
De typische tang-structuur van WML wordt ook hier mooi geïllustreerd.
Het eerste select-element omvat vijf keuzes, die allemaal volgens bovenstaande syntax opgebouwd zijn. De begintag
<option value="MON">
specificeert welke waarde
in de variabele day (gedeclareerd in het select-element) moet
worden gestopt als de gebruiker kiest voor de optie die aangegeven
wordt met de omschrijving die in dit geval Monday is. De omschrijving
is het stukje tekst dat door de begin- en eindtag van het option-element
worden omgeven. Het element wordt afgesloten met de eindtag
</option>
.
Als we ook Saturday als mogelijkheid willen voorzien, zal een extra element bijgemaakt worden met volgend stukje code:
Voorbeeld: <option value="SAT"> Saturday </option>
Als de vijf mogelijke opties zijn ingegeven, kunnen we dit eerste
keuze-element afsluiten met de eindtag </select>
.
Zoals in de opzet van de applicatie was bepaald, waren drie parameters noodzakelijk om te kunnen bepalen welk college van toepassing is voor de student. Daarom worden binnen deze card ook nog de twee andere parameters aangemaakt: de cyclus (Cycle) en de les (Course). Hier ook steeds hetzelfde principe: eerst wordt de keuzelijst aangemaakt en vervolgens worden de mogelijke waarden toegevoegd, met hun waarde en omschrijving. De lezer zal deze waarden opnieuw zien verschijnen in het script. Want met die waarden zal de procedurele logica gestuurd worden!
Zo kan men dus vaststellen dat voor de parameter Cycle drie mogelijke waarden kunnen geselecteerd worden, met name Morning, Afternoon of Evening die als respectievelijke waarde voor de variabele Cycle "MO", "AF" of "EV" kunnen hebben.
Anders gezegd: kiest de gebruiker voor Morning uit de keuzelijst, dan wordt in de variabele Cylcle de waarde "MO" opgeslagen. Daarmee wordt dan gerekend in de WMLScriptfunctie die achter de applicatie steekt.
De keuzelijsten die we hebben besproken, vormen ongetwijfeld een zeer krachtig element om de invoer van gegevens te vereenvoudigen. Dit is erg handig, wanneer we terugdenken aan de beperkingen die we in hoofdstuk drie hebben omschreven. Natuurlijk moet men er zich van bewust zijn dat keuzelijsten soms niet gebruikt kunnen worden, bijvoorbeeld als men vraagt naar de geboortedatum van de gebruiker.
Tenslotte, om dit eerste deel van de derde card te beëindigen, moeten we nog speciale aandacht schenken aan de regel code die in het vet staat gemarkeerd in het code-venster. Deze regel is van uiterst belang voor het welslagen van de uitvoering van de applicatie, en wel omdat deze de brug vormt tussen de twee onderdelen van de applicatie: deze regel roept het resultaat op van de WMLScriptfunctie die zal nagaan welk college moet worden getoond:
<br/>
betekent dat we een break inlassen, een nieuwe regel dus
<u>
onderlijnt het getoonde resultaat (tekstopmaak)
<b>
zet het getoonde resultaat in vet (tekstopmaak)
$(assignment)
plaatst het resultaat van de WMLScriptfunctie
Samenvattend kunnen we dus stellen dat we in deze card reeds de mogelijkheid hebben voorzien voor de gebruiker om de drie parameters die nodig zijn voor het bepalen van het college te selecteren, en er is ruimte voorzien om het betreffende college weer te geven. Dat college is het resultaat van de WMLScriptfunctie die achter de applicatie steekt. We hoeven nu enkel nog te weten hoe we aan de applicatie kunnen duidelijk maken dat een bepaald script moet worden uitgevoerd, en hoe we onze variabelen daaraan kunnen meegeven. Zij vormen immers de basis waarmee de WMLScriptfunctie zal werken.
Onderstaand kader toont het vervolg van de code van de derde card in het deck. Als we terugkijken naar het eerste deel van de code van card drie, dan zien we inderdaad dat we driemaal een keuzelijst hebben gecreëerd om deze drie parameters te beschrijven, en we tevens bij elk van deze declaraties een variabele hebben genoemd om de gekozen waarde in op te slaan. Deze variabelen, respectievelijk day, cycle en course komen nu dus terug als vereiste argumenten voor de functie assign.
<do type="accept" label="Show Result" name="a"> <go href="code.wmls#assign('assignment','$(day)','$(cycle)','$(course)')"/> </do> <do type="accept" label="Help!" name="b"> <go href="#card4"/> </do> <do type="accept" label="Info" name="c"> <go href="#card5"/> </do> </p> </card>
In dit deeltje code introduceren we een nieuw element:
het do
element. Zoals reeds werd gezegd, voert het do
element
bepaalde taken uit. Via dit element gaan we een aantal items
creëren die de gebruiker zal kunnen uitvoeren als hij
naar het optiemenu van zijn GSM-toestel gaat.
Meer bepaald gaan we voorzien dat de gebruiker, eens hij de parameters dag, cyclus en les heeft ingegeven, kan opvragen welk college hij heeft. De gebruiker kan informatie opvragen rond de auteur van de applicatie en tenslotte kan hij ook een helpscherm raadplegen. Alle opties kunnen dus zoals gezegd via het menu opties van het toestel geraadpleegd worden.
Bij nauwkeurig onderzoek van het stukje code dat boven aan deze bladzijde staat,
kan men meteen zien dat er drie
do
elementen worden gemaakt. De declaratie van het
do
element bevat steeds drie verplichte attributen:
het type, een label (= de omschrijving van de keuzemogelijkheid in
het optiesmenu van de GSM) en een naam, die hier wel verplicht is
maar opnieuw voornamelijk een documentatiefunctie heeft voor de ontwikkelaar.
Tussen de starttag en de eindtag specificeert de ontwikkelaar dan de taak die moet worden uitgevoerd als het betreffende item wordt gekozen uit de optielijst van de GSM.
Het eerste do element, dat verschijnt onder de naam "Show Result" in het optiemenu van het toestel, roept een WMLScriptfunctie aan, de functie assign. Deze functie is door de ontwikkelaar zelf ontwikkeld (zie paragraaf 6.6). Deze functie krijgt een aantal parameters mee, die tussen haakjes worden vermeld. Als we de declaratie bekijken, dan kunnen we lezen dat deze functie assign het resultaat wegschrijft in de variabele assignment, en hiervoor drie variabelen nodig heeft: een day, een cycle en een course. En dat zijn precies de drie parameters die wij voorzien hadden.
Het eerste do
element creëert een item dat de
gebruiker toestaat om het college op te zoeken. Daarvoor is de
go-taak nodig, waarmee men kan aangeven naar welke functie moet
gegaan worden. De lezer kan vaststellen dat het go-element een
zogenaamd "leeg" element is, vermits er geen eindtag voor is.
De syntax van het go-element is dus algemeen:
Syntax: <go href="navigatie-pad"/>
Dat navigatiepad kan ofwel een referentie zijn naar een card
die moet worden getoond, zoals de laatste twee do
-elementen,
of een verwijzing zijn naar het WMLScript dat moet gebruikt worden.
En dat gebeurt in het eerste do
-element. De functie
assign wordt opgeroepen, en deze functieaanroep heeft twee
elementen nodig:
Het resultaat van de functie assign wordt dan in het deck
gesubstitueerd op de plaats waar dit werd voorzien door
de syntax $(assignment)
.
De overige twee do
elementen zijn iets eenvoudiger.
Zij roepen geen functie aan, maar gaan eenvoudigweg navigeren naar
een bepaalde card. Dat gebeurt eveneens via de go-taak, door het
meegeven van de naam van de betreffende card die moet getoond
worden, of een navigatiepad als de card zich niet in hetzelfde deck bevindt.
<do type="accept" label="Info" name="c"> <go href="#card5"/> </do>
Deze do
zorgt ervoor dat wanneer de gebruiker Info kiest uit zijn menu en bevestigt, er automatisch een nieuwe card uit het deck wordt geladen. Het betreft de card met als unieke naam card5. De samenstelling van die card volgt hieronder, na de code voor de vierde card. Het derde
do
element voorziet een analoge vorm van navigeren. Kiest de gebruiker voor het item Help, dan navigeert het systeem automatisch naar card4.
De opbouw van deze card4 is zeer eenvoudig, en bevat een laatste nieuw element dat de navigatie voor de gebruiker heel wat vereenvoudigt.
<card id="card4" title="Help!"> <p align="center"> To find the right course, choose a day, a cycle and a course. Then go to OPTIONS, and select "Show Result". The course is then displayed. <do type="prev" label="Back" name="d"> <prev/> </do> </p> </card>
De declaratie van de card stelt geen probleem meer, ook de gewone tekst
kennen we onderhand al. We stellen echter vast dat in deze card ook een
do
element zit, dat we nog niet kennen. Zoals in hoofdstuk
drie werd vermeld, kan zo'n
do
element ver verschillende taken uitvoeren. Want do
verwijst naar een actie die moet uitgevoerd worden. Op de vorige pagina
hebben we al de go
beschreven, nu komt de tweede taak prev
aan bod. Deze voorziet dat de gebruiker terug naar de voorgaande
card kan navigeren. Via het type-attribuut van het
do
element kunnen we dit bepalen. De structuur is analoog
met de go
elementen die we in de derde card hebben besproken,
enkel de syntax is eenvoudiger. We weten reeds dat het go
element drie verplichte attributen heeft: een type, een label en een naam.
In card drie waren de go
elementen van het type accept
,
nu zijn ze van het type prev
. Wat doet dit
do
element? Als de gebruiker drukt op het item met als label
Back, wordt terug genavigeerd naar de vorige card uit het deck.
In tegenstelling met het go
elementen moet bij het prev
element geen lange href
opgenomen worden, omdat het toestel
zelf automatisch de geschiedenis bijhoudt, en er dus een eenvoudige
pop-operatie plaatsvindt op de geschiedenis. Enkel de lege tag
<prev/>
volstaat om duidelijk te maken aan
de browser dat naar de vorige card moet worden genavigeerd.
Ook in card 5 vinden we dit geval terug. Als de gebruiker in het helpscherm is aanbeland, en dit heeft doornomen, kan hij eenvoudig terugkeren door op de Back te drukken. De code van de vijfde card vindt de lezer in onderstaand kader:
<card id="card5"> <p align="center"> <img src="email.wbmp" alt="info"/> </p> <p align="center"> Mailto: s.lombaert@pi.be </p> <do type="prev" label="Back" name="e"> <prev/> </do> </card> </wml>
Niets nieuws onder de zon. Er wordt een figuur getoond, samen met een stukje tekst, en er wordt een Back functionaliteit voorzien.
Tenslotte eindigt het document met de eindtag </wml>.
Hieronder vindt de lezer de listing van de code.
<?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <card id="card1" ontimer="#card2"> <timer value="20"/> <p align="center"> <img src="logo.wbmp" alt="logo"/> </p> </card> <card id="card2" ontimer="#card3"> <timer value="30"/> <p align="center"> <img src="esearch.wbmp" alt="e-search"/> </p> <p align="center"> Welcome to E-Search! </p> </card> <card id="card3" > <p> Day: <select name="day" title="Day"> <option value="MON">Monday</option> <option value="TUE">Tuesday</option> <option value="WED">Wednesday</option> <option value="THU">Thursday</option> <option value="FRI">Friday</option> </select> Cycle: <select name="cycle" title="Cycle"> <option value="MO">Morning</option> <option value="AF">Afternoon</option> <option value="EV">Evening</option> </select> Course: <select name="course" title="Course"> <option value="F">First</option> <option value="S">Second</option> </select> <br/>=><u><b>$(assignment)</b></u> GO.WML - Listing <do type="accept" label="Show Result" name="a"> <go href="code.wmls#assign('assignment','$(day)','$(cycle)','$(course)')"/> </do> <do type="accept" label="Help!" name="b"> <go href="#card4"/> </do> <do type="accept" label="Info" name="c"> <go href="#card5"/> </do> </p> </card> <card id="card4" title="Help!"> <p align="center"> To find the right course, choose a day, a cycle and a course. Then go to OPTIONS, and select "Show Result". The course is then displayed. <do type="prev" label="Back" name="d"> <prev/> </do> </p> </card> <card id="card5" title="Info"> <p align="center"> <img src="email.wbmp" alt="info"/> </p> <p align="center"> Mailto: s.lombaert@pi.be </p> <do type="prev" label="Back" name="e"> <prev/> </do> </card> </wml> GO.WMLS – Listing Continued
Zoals gezegd is de (eventuele) tweede component van een applicatie de WMLScriptfunctie die procedurele logica toevoegt aan de toepassing. Ook in de voorbeeldapplicatie is een stuk WMLScript geprogrammeerd, met name de functie assign die in de bibliotheek code.wmls zit. Deze paragraaf wil de opbouw van de code kort even toelichten. De lezer zal merken dat de bespreking van de code van de WMLScriptfunctie minder uitgebreid is dan deze van de toepassing zelf, omdat het schrijven van WMLScriptfuncties nauw aansluit bij gewone scripttalen, en het bovendien niet tot de scope van dit werk behoort om de lezer te scholen in klassieke procedurele programmeertalen. Toch worden de belangrijkste elementen even toegelicht.
Wat betreft de logica achter de functie kunnen we kort zijn: er zit een reeks geneste if-then-else constructies achter, zodat elke mogelijkheid kan worden achterhaald. Maar dat is van ondergeschikt belang, zoals reeds werd verantwoord.
Het eerste deel van de code ziet eruit als volgt:
extern function assign(varName,day,cycle,course) { var returnString; if (day == "MON") { if (cycle=="MO") { if (course=="F") returnString="No class!"; else if (course=="S") returnString="Fin. Beleid"; } else if (cycle=="AF") { if (course=="F") returnString="Fisc. Recht"; else if (course=="S") returnString="No Class!"; } else if (cycle="EV") { if (course=="F") returnString="No Class!"; else if (course=="S") returnString="No Class!"; }
Belangrijk zijn de eerste twee regels. De eerste regel definieert
de functie assign
. Als uitvoer heeft die dus een variabele
die we zelf kunnen kiezen. Wanneer de lezer gaat terugkijken naar, dan
zal hij merken dat we voor de naam assignment hebben gekozen. Bovendien
zijn er drie verplichte argumenten: een day, een cycle en een course.
In de tweede regel wordt dan een variabele returnString geïnitialiseerd, die dan de waarde van het eventuele college zal bevatten. Als bijvoorbeeld de parameters die aan de functie worden meegegeven onderstaande waarden te hebben:
? day = MON (betekenis: gebruiker heeft Monday geselecteerd uit de keuzelijst bij Day) ? cycle = MO (betekenis: gebruiker heeft Morning geselecteerd uit de keuzelijst bij Cyle) ? course = S (betekenis: de gebruiker heeft de tweede mogelijkheid gekozen)
dan zal de waarde van de variabele returnString gelijk worden aan “Fin. Beleid”. Met andere woorden, op dat tijdstip wordt de student geacht om het college Financieel Beleid te volgen.
We slaan de rest van de code over (de lezer kan die wel nalezen in paragraaf 6.7) en bekijken het einde van de code van de functie. Deze ziet eruit als volgt:
WMLBrowser.setVar(varName,returnString); WMLBrowser.refresh(); }
De code eindigt met het gebruik van twee functies uit een van
de standaard-bibliotheken die beschikbaar zijn voor de ontwikkelaar.
De functie setVar
uit de WMLBrowser bibliotheek wijst
de door ons gekozen naam (die we dan gebruiken om het resultaat
van de WMLScriptfunctie in onze card te brengen) toe aan de variabele
returnString (waarin het resultaat zit).
Tenslotte zorgt de functie refresh
, eveneens uit de
standaardbibliotheek WMLBrowser, ervoor dat alles weer op nul gezet
wordt, zodat een nieuwe zoektocht kan beginnen. Deze refresh
zet als het ware alles weer op nul, zodat steeds een identieke beginsituatie
bekomen wordt. De bijhorende accolade sluit het geheel af.
Voor die lezer die de volledige code nog eens wil nalezen, verwijzen we graag naar paragraaf 6.7 waar de volledige code is opgenomen.
extern function assign(varName,day,cycle,course) { var returnString; if (day == "MON") { if (cycle=="MO") { if (course=="F") returnString="No class!"; else if (course=="S") returnString="Fin. Beleid"; } else if (cycle=="AF") { if (course=="F") returnString="Fisc. Recht"; else if (course=="S") returnString="No Class!"; } else if (cycle="EV") { if (course=="F") returnString="No Class!"; else if (course=="S") returnString="No Class!"; } } else if (day == "TUE") { if (cycle=="MO") { if (course=="F") returnString="No Class!"; else if (course=="S") returnString="No Class"; } else if (cycle=="AF") { if (course=="F") returnString="No Class!"; else if (course=="S") returnString="No Class!"; } else if (cycle="EV") { if (course=="F") returnString="No Class!"; else if (course=="S") returnString="No Class!"; } } else if (day == "WED") { if (cycle=="MO") { if (course=="F") returnString="No Class!"; else if (course=="S") returnString="No Class!"; } else if (cycle=="AF") { if (course=="F") returnString="Fisc. Recht"; else if (course=="S") returnString="Act.Ec.Topics"; } else if (cycle="EV") { if (course=="F") returnString="Energie-ec."; else if (course=="S") returnString="No Class!"; } CODE.WMLS Listing } else if (day == "THU") { if (cycle=="MO") { if (course=="F") returnString="No Class!"; else if (course=="S") returnString="No Class!"; } else if (cycle=="AF") { if (course=="F") returnString="No Class!"; else if (course=="S") returnString="Database"; } else if (cycle="EV") { if (course=="F") returnString="Soft-engin."; else if (course=="S") returnString="No Class!"; } } else if (day == "FRI") { if (cycle=="MO") { if (course=="F") returnString="No Class!"; else if (course=="S") returnString="No Class!"; } else if (cycle=="AF") { if (course=="F") returnString="No Class!"; else if (course=="S") returnString="No Class!"; } else if (cycle="EV") { if (course=="F") returnString="No Class!"; else if (course=="S") returnString="No Class!"; } } WMLBrowser.setVar(varName,returnString); WMLBrowser.refresh(); } CODE.WMLS Listing Continued
Wanneer het deck en de bijhorende code zijn ontwikkeld, kan de gebruiker deze uitgebreid testen in de Nokia WAP Toolkit, en ook simulaties uitvoeren. Op die manier krijgt men een goed idee van wat werkelijk op de mobiele terminal zal verschijnen.
Als alles “bug-free” kan verklaard worden, is het moment aangebroken om de toepassing ook effectief ter beschikking te stellen van de gebruiker. Hoe dat kan gebeuren, wordt in het volgende hoofdstuk besproken.