vorige
volgende
inhoudstafel


Hoofdstuk 6: De applicatie e-Search

6.1 Inleiding

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.

6.2 Doel van de applicatie

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.

Maandag...Vrijdag, 8h30...19h30, diverse vakken
Figuur 26: het gebruikte collegerooster

Ter illustratie twee voorbeelden, waarbij de drie parameters weergegeven worden:

a) Software-engineering:

b) Financieel Beleid:

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.

6.3 Componenten

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

6.4 De applicatie: stap voor stap

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:

EHSAL-logo
Figuur 30: e-Search schermuitvoer van card 1

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:

E-Search-logo
Figuur 31: e-Search schermuitvoer van card 2

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>.

6.5 e-Search: de volledige code

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

6.6 De functie: stap voor stap

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.

6.7 De functie: de volledige code

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.


vorige
volgende
inhoudstafel