Implementatie van de UIML standaard in UIML.NET

Eindwerk voorgedragen tot het behalen van de graad van bachelor in de Informatica/ICT/Kennistechnologie

Implementatie van de UIML standaard in UIML.NET Ingo Berben

Promotor: dr. Kris Luyten Co-promotor: Prof. dr. Karin Coninx Begeleider: Jo Vermeulen

Academiejaar 2006 - 2007

Dankwoord Ik zou graag mijn dankbaarheid betuigen aan de mensen die mij geholpen hebben bij het maken van dit eindwerk. Als eerste mijn promotor, dr. Kris Luyten om mij de kans te geven om mijn eindwerk te houden over een project wat hijzelf opgestart heeft, namelijk UIML.NET en voor het nakijken van mijn tekst. Ook Karin Coninx, mijn co-promotor ben ik dankbaar. Verder zou ik mijn begeleider Jo Vermeulen willen bedanken voor het uitleggen van de code die dr Kris Luyten en hijzelf al hadden geschreven, voor de vele idee¨en ter verbetering van mijn tekst. Ook wil ik hem bedanken voor de zeer nuttige en inzichtvolle conversaties over de implementatie van mijn thesis. Voor het maken van een demo applicatie in XAML zou ik graag Gert Van Gool willen bedanken. De mensen van i-VISIT ben ik dankbaar voor het lenen van een PDA om de implementatie te testen op het compact framework. Verder zou ik mijn ouders en mijn zus willen bedanken voor de steun bij mijn studies, vooral tijdens de moeilijke en stressvolle periodes, zoals de examens. Als laatste zou ik vrienden en vriendinnen willen bedanken voor de steun die zij hebben gegeven tijdens mijn studies en voor de fijne samenwerking om al de projecten tot een goed einde te brengen. Algemeen wil ik nog zeggen dat ik iedereen dankbaar ben voor het geven van voldoende ruimte om mij de mogelijkheid te geven optimaal te werken, maar toch de nodige ondersteuning en het duwtje in de rug te geven wanneer dit nodig was.

1

Inhoudsopgave 1 Inleiding

1

2 UIDL - User Interface Description Language

3

2.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2

UIDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2.1

GladeXML . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2.2

XAML . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

HLUIDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.3.1

XForms . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.3.2

UIML . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.3.3

XUL . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.3

2.4

3 UIML - User Interface Markup Language

16

3.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

3.2

Doel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.3

Elementen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.3.1

Interface . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.3.2

Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.3.3

Templates . . . . . . . . . . . . . . . . . . . . . . . . .

24

i

4 Behavior

26

4.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.2

Opbouw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.3

Condities . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.4

Op . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.5

Evaluatie van condities . . . . . . . . . . . . . . . . . . . . . .

28

5 UIML.NET

30

5.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

5.2

Architectuur[LTVC] . . . . . . . . . . . . . . . . . . . . . . .

30

5.3

Backends . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

5.4

Huidige implementatie van condities . . . . . . . . . . . . . .

32

6 Implementatie

35

6.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

6.2

Problemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

6.2.1

Kijken naar events . . . . . . . . . . . . . . . . . . . .

36

6.2.2

Event uitsturen . . . . . . . . . . . . . . . . . . . . . .

37

6.2.3

Kijken of een property verandert . . . . . . . . . . . .

37

Condition manager . . . . . . . . . . . . . . . . . . . . . . . .

39

6.3.1

Anonieme delegates . . . . . . . . . . . . . . . . . . .

40

6.3.2

De linker . . . . . . . . . . . . . . . . . . . . . . . . .

40

6.3.3

De manager . . . . . . . . . . . . . . . . . . . . . . . .

42

6.3

7 Uitgebreid voorbeeld

44

Conclusie

52

A Registreer formulier

53

ii

Lijst van figuren 2.1

Verschillende benamingen voor hetzelfde widget . . . . . . . .

4

2.2

XML mapping van button op System.Windows.Forms.Button

5

2.3

Resultaat van listing 2.2 . . . . . . . . . . . . . . . . . . . . .

6

2.4

Resultaat van listing 2.3 . . . . . . . . . . . . . . . . . . . . .

8

2.5

Verschillende apparaten . . . . . . . . . . . . . . . . . . . . .

9

2.6

Model-View-Controller patroon[Wik07a] . . . . . . . . . . . .

10

2.7

Resultaat van listing 2.4 . . . . . . . . . . . . . . . . . . . . .

10

2.8

Resultaat van listing 2.5 . . . . . . . . . . . . . . . . . . . . .

12

3.1

Het verschil tussen specifieke en generieke elementen, in dit voorbeeld tussen en <part> . . . . . . . . . . . . .

17

3.2

Structuur van een UIML document[LVC]

. . . . . . . . . . .

19

3.3

Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.4

Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

4.1

Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.2

Willekeurig diep nesten . . . . . . . . . . . . . . . . . . . . .

28

5.1

Werking van een gekoppelde delegate . . . . . . . . . . . . . .

34

6.1

Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

6.2

Het linken en checken van events . . . . . . . . . . . . . . . .

41

6.3

Het plaatsvinden van een event . . . . . . . . . . . . . . . . .

43

7.1

Screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

7.2

Checken of het invoerveld firstName niet leeg is . . . . . . .

51

iii

Listings 2.1

Gesynchroniseerde toegang tot een variabele . . . . . . . . . .

4

2.2

XAML Demo . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.3

XAML Mouse Over Voorbeeld . . . . . . . . . . . . . . . . .

7

2.4

XForms Card Voorbeeld . . . . . . . . . . . . . . . . . . . . .

11

2.5

XUL Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.1

UIML Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . .

18

3.2

<structure> . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.3

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.4

<presentation> . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.5

Template invoegen . . . . . . . . . . . . . . . . . . . . . . . .

25

4.1

Equal && Op . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.2

Geneste . . . . . . . . . . . . . . . . . . . . . . . . . .

29

5.1

Delegate Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . .

33

6.1

ILGenerator Voorbeeld . . . . . . . . . . . . . . . . . . . . . .

38

6.2

Wrapper rond een event handler . . . . . . . . . . . . . . . .

40

6.3

Execute functie . . . . . . . . . . . . . . . . . . . . . . . . . .

42

7.1

<structure> element . . . . . . . . . . . . . . . . . . . . . .

44

7.2

<style> element . . . . . . . . . . . . . . . . . . . . . . . . .

45

7.3

Het leegmaken van het formulier . . . . . . . . . . . . . . . .

46

7.4

Kijk of alle velden zijn ingevuld . . . . . . . . . . . . . . . . .

46

7.5

Kijk of er ´e´en of meerdere velden niet zijn ingevuld . . . . . .

47

7.6

Het gebruik van templates om de regels te combineren . . . .

47

A.1 UIML Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . .

53

iv

Hoofdstuk 1

Inleiding Het merendeel van de mensen gebruikt tegenwoordig een computer, zowel op persoonlijk als op werk niveau. Het is een platform dat ge¨ıntegreerd is in onze samenleving. Andere ge¨ıntegreerde platformen zijn de GSM, de smartphone en de Personal Digital Assistant (PDA). Op al deze platformen of apparaten draaien software programma’s die ervoor zorgen dat de uiteindelijke gebruiker gemakkelijk met het platform kan interageren. Er is dus een brede waaier aan keuzemogelijkheden als het er op een aankomt een persoonlijk apparaat aan te schaffen. Als we aan de kant van de software ontwikkelaar gaan kijken, ligt het allemaal een stuk moeilijker. Meerdere platformen wil zeggen meer programmeertalen, meer veranderingen, meer problemen. Er is nood aan user interface (UI) tools die multi-device UI ontwikkeling toelaten[LTVC]. De bedoeling van dit eindwerk is het uitbreiden van UIML.NET zodat het de UIML standaard beter ondersteunt. UIML is een High Level User Interface Description Language en kan bekeken worden als een metataal die kan gebruikt worden om de vier verschillende aspecten van een UI (structure, style, content en behavior) te beschrijven[LTVC]. De nadruk van dit eindwerk ligt vooral op het vierde aspect (behavior), namelijk het implementeren van conditionele testen. Om te beginnen zal eerst een beschrijving gegeven worden van User Interface Description Languages (UIDL) en High-Level User Interface Description Languages (HLUIDL) met enkele voorbeelden. Vervolgens zal er verder uitgeweid worden over de HLUIDL taal UIML. Er wordt uitgelegd hoe deze taal in elkaar zit en wat de mogelijkheden ervan zijn. Omdat dit eindwerk vooral over het gedrag van een User Interface (UI) naar de eindgebruiker gaat, zal dit het volgende punt zijn dat meer in detail besproken wordt. 1

Verder zullen enkele details over de implementatie besproken worden en als laatste volgt er een uitgebreid voorbeeld.

2

Hoofdstuk 2

UIDL - User Interface Description Language 2.1

Inleiding

Tegenwoordig bestaan er verschillende talen om een user interface (UI) te programmeren. Enkele voorbeelden hiervan zijn System Windows Forms (SWF), de grafische UI toolkit van Microsoft1 die ge¨ıntegreerd is met het .NET platform; Java Swing, de grafische UI toolkit voor het Java platform; GTK , Qt, enzovoorts. Het gebruik van deze toolkits brengt echter enkele problemen met zich mee. Ten eerste gebruiken ze hun eigen benamingen. Als we een label willen aanmaken, moeten we in SWF gebruik maken van de klasse System.Windows.Forms.Label, terwijl Java Swing hiervoor de klasse javax.swing.JLabel heeft (zie figuur 2.1). Het gebruik van verschillende benamingen slaat niet enkel op klasses, maar ook op functies. Ten tweede gebruiken ze verschillende code structuren. Een voorbeeld hiervan is het zorgen dat slechts ´e´en thread aan een variabele kan. In SWF wordt gebruikt gemaakt van het sleutelwoord lock, in Java volstaat het om gewoon het sleutelwoord synchronized te gebruiken bij het aanmaken van de functie. In listing 2.1 zien we een voorbeeld. De functie increase() verhoogt de waarde van een teller. Het is dus voor de UI ontwerper moeilijk om verschillende toolkits te gebruiken voor elk platform. 1

http://www.microsoft.com

3

Figuur 2.1: Verschillende benamingen voor hetzelfde widget Listing 2.1: Gesynchroniseerde toegang tot een variabele 1 2 3 4 5 6 7 8

[SWF => C#] public void i n c r e a s e ( ) { lock ( counter ) { c o u n t e r ++; } }

9 10 11 12 13 14

[ Java Swing => Java ] public synchronized void i n c r e a s e () { c o u n t e r ++; }

2.2

UIDL

Sinds de opkomst van mobiele toestellen is de nood gekomen voor een meer algemene methode voor het maken van UI’s. Een UIDL of User Interface Description Language wordt gebruikt om een UI te beschrijven. Het is gebonden aan een specifieke UI toolkit, zoals GladeXML of XAML die later zullen uitgelegd worden. Het beschrijven van de UI kan gebeuren in bijvoorbeeld XML. Een XML tag kan dan worden gemapt op een UI element (zie figuur 2.2), waardoor er minder programmeerkennis nodig is om een UI te ontwerpen.

2.2.1

GladeXML

GladeXML is een formaat dat door het programma Glade Interface Designer2 wordt gebruikt voor het voorstellen van UI’s. In dit XML-formaat wordt gebruikt gemaakt van de volgende tags: 2

http://glade.gnome.org/

4

Figuur 2.2: XML mapping van button op System.Windows.Forms.Button <widget> om een bepaald widget voor te stellen, bijvoorbeeld <widget class=‘‘GtkWindow’’ id=‘‘MainWindow’’>... stelt een window voor met id ’MainWindow’. Om properties te veranderen <property> om een property van een widget te wijzigen, bijvoorbeeld <property name=‘‘visible’’>True om een widget zichtbaar te maken om kinderen van een widget te defini¨eren, bijvoorbeeld ... <signal> om een event te koppelen, bijvoorbeeld <signal name=‘‘clicked’’ handler=‘‘button clicked’’ /> zal het ’clicked’ event koppelen aan de functie ’button clicked’ voor het widget waarin deze tag gedefinieerd is.

2.2.2

XAML

XAML [Mic07b] of eXtensible Application Markup Language is een declaratieve, XML-gebaseerde, taal dat het ontwikkelen van UI’s vergemakkelijkt. Het ondersteunt zowel vector als bitmap graphics, multimedia bestanden en rich text. XAML is een deel van het .NET 3.0[Mic07a] framework van

5

Microsoft en wordt vooral gebruik in combinatie met Windows Presentation Foundation (WPF), voor het beschrijven van UI elementen, events, data binding, . . . . WPF is het UI subsysteem in Windows Vista3 , het nieuwste besturingssysteem van Microsoft. Het haalt zijn voordeel uit de ge¨ avanceerde 3D graphics capaciteiten in moderne machines. Een voorbeeld hiervan is de “Aero” skin die een transparant, op glas gebaseerde window randen geeft[Enc07]. Momenteel is XAML enkel beschikbaar voor het Windows platform. Een voorbeeld hoe je XAML programmeert, is te vinden in listing 2.2, waarin eerst een grid wordt gemaakt waarin later enkele widgets worden geplaatst. Deze grid definieert de achtergrondkleur en de hoogte voor iedere rij (100px). Hierna wordt er een textbox en een knop (button) in deze grid geplaatst. Het resultaat is te vinden in figuur 2.3[Goo07]. XAML heeft zogenaamde ’Property Triggers’ ingebouwd die toestaan om zonder logische code, bepaalde gebeurtenissen te beschrijven samen met de actie die moet worden uitgevoerd als deze gebeurtenis zich voordoet. In listing 2.3 is te zien dat er een rechthoek wordt getekend op het scherm. Aan deze rechthoek worden enkele propertytriggers gekoppeld. Wanneer er met de muis over de rechthoek wordt bewogen, wordt de rechthoek opgevuld met een groene kleur en wordt de zichtbaarheid op 100% gezet. Wanneer de rechthoek niet langer actief is, worden zowel de rand als de rechthoek zelf grijs ingekleurd. Het resultaat van de verschillende stappen is te vinden in figuur 2.4. Events kunnen gemakkelijk gekoppeld worden. Iedere event wordt gezien als een attribuut waaraan de functie kan gekoppeld worden die moet worden opgegeroepen wanneer dit event plaatsvindt. Stel dat we een object van het type Canvas hebben en we zijn ge¨ınteresseerd in het event Loaded, dan volstaat het om in de code te zetten: .

Figuur 2.3: Resultaat van listing 2.2 3

http://www.microsoft.com/netherlands/windows/products/windowsvista/default.mspx

6

Listing 2.2: XAML Demo 1 2 3 4 5 6

<Window xmlns=” h t t p : // schemas . m i c r o s o f t . com/ w i n f x /2006/ xaml / p r e s e n t a t i o n ” x m l n s : s y s=” c l r −namespace:System ; assembly=m s c o r l i b ” x m l n s : x=” h t t p : // schemas . m i c r o s o f t . com/ w i n f x /2006/ xaml ”> <Window . T i t l e>Demo <Window . H eigh t>200 <Window . Width>200

7 8 9 10 11 12 13 14 15 16 17

100

18 19 20 21 22

H e l l o world ! <Button Grid . Column=” 0 ” Grid . Row=” 0 ”>C l i c k me !

Listing 2.3: XAML Mouse Over Voorbeeld 1 2 3 4 5 6 7 8 9 10 11 12 13 14

<S t y l e> <S t y l e . V i s u a l T r i g g e r s>

<S e t PropertyPath=” F i l l ” Value=” g r e e n ” /> <S e t PropertyPath=” Opacity ” Value=” 1 . 0 ” />

<S e t PropertyPath=” F i l l ” Value=” gray ” /> <S e t PropertyPath=” S t r o k e ” Value=” gray ” />

7

Figuur 2.4: Resultaat van listing 2.3

2.3

HLUIDL

Een HLUIDL of High-level User Interface Description Language gaat nog een stap verder. Zoals de naam het al zegt is dit een taal op een hoger niveau dan een UIDL. Het biedt de mogelijkheid om een apparaat-onafhankelijke en abstracte beschrijving van een gebruikersinterface te cre¨eeren met een taal die gemakkelijk te gebruiken is in heterogene omgevingen. Een heteregone omgeving wil zeggen dat er gebruik gemaakt wordt van verschillende soorten hard- en software van verschillende producenten. De extra laag die HLUIDL voorziet zorgt ervoor dat er met een document een applicatie kan gerenderd worden die platform- en toolkit-onafhankelijk wordt. Applicaties kunnen dus met min of meer hetzelfde document op verschillende apparaten draaien (zie figuur 2.5) zoals bijvoorbeeld een PDA, desktop computer, smartphone, .... Met de kennis van enkel de syntax van een HLUIDL kan je programma’s ontwikkelen die gemakkelijk uit te breiden en herbruikbaar zijn op verschillende platformen. Ondanks dat verschillende HLUIDs geen gebruik maken van XML, is XML toch de meest aangewezen taal voor het beschrijven van HLUIDs [Luy04]. Daar XML een declaratieve taal is, kan het ook gebruikt worden door niet-programmeurs of occasionele gebruikers [SV03].

2.3.1

XForms

XForms is een XML formaat dat origineel bedoeld was om HTML4 en XHTML5 te vervangen. Het kan echter ook op een stand-alone manier gebruik worden om UI’s te beschrijven. In tegenstelling tot HTML hebben de ontwerpers van XForms zich gebaseerd op het Model-View-Controller patroon. 4 5

HyperText Markup Language eXtensible HyperText Markup Language

8

Figuur 2.5: Verschillende apparaten Dit is een patroon dat gebruikt wordt in software engineering. De data wordt gescheiden van de UI, zodat veranderingen aan de UI geen effect zullen hebben op de afhandeling van de data en dat data gere¨organiseerd kan worden zonder de UI te veranderen[Wik07a]. In figuur 2.6 zien we een schematische voorstelling van het Model-View-Controller patroon. Door het gebruik van het Model-View-Controller patroon wordt het mogelijk om formulieren, gemaakt met XForms, te hergebruiken omdat deze niet afhankelijk zijn van de pagina waarop ze gebruikt worden. Bovendien is XForms niet langer beperkt tot XHTML, het kan ge¨ıntegreerd worden in iedere markup language. Een voorbeeld van XForms is te vinden in listing 2.4. In dit voorbeeld zien we dat er een model wordt gemaakt in de tag . Dit is een soort van template, die later gebruikt kan worden in de body. <xforms:input ref="method"> komt overeen met <method/>. input wil zeggen dat dit item als een textbox moet worden weergegeven (zie figuur 2.7). De tag xforms:label is het label dat voor de textbox komt te staan. XForms laat het defini¨eren van regels toe[Ltd04], zo wordt bepaald hoe een formulier zich gedraagd zonder de nood voor scripting. De types van 9

Figuur 2.6: Model-View-Controller patroon[Wik07a] regels die gebruikt kunnen worden zijn verdeeld in statische en dynamische eigenschappen.

Figuur 2.7: Resultaat van listing 2.4

2.3.2

UIML

User Interface Markup Language (UIML) laat toe om op een abstracte manier UI’s te beschrijven. De op XML gebaseerde beschrijving van de UI kan gemapt worden op ´e´en of meerdere UI toolkits. Het maakt geen gebruik van specieke elementen zoals

, maar gebruikt het generieke element <part> dat op eender welk widget gemapt kan worden. Meer hierover in hoofdstuk 3.

2.3.3

XUL

XML User interface Language (XUL) is ontwikkeld voor gebruik in het Mozilla6 project. Deze UI taal is gebaseerd op XML en laat toe om applicaties 6

http://www.mozilla.org

10

Listing 2.4: XForms Card Voorbeeld 1 2 3 4 5 6 7 8 9 10 11 12

13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

< t i t l e>Pay I n f o <x f o r m s : m o d e l> <x f o r m s : i n s t a n c e> <ecommerce xmlns=” ”> <method/> <e x p i r y /> <x f o r m s : s u b m i s s i o n a c t i o n=” h t t p : // example . com/ submit ” method=” p o s t ” i d=” submit ” i n c l u d e n a m e s p a c e p r e f i x e s=” ” /> <x f o r m s : s e l e c t 1 r e f=”method”> <x f o r m s : l a b e l>S e l e c t Payment Method: <x f o r m s : i t e m> <x f o r m s : l a b e l>Cash <x f o r m s : v a l u e>c a s h <x f o r m s : i t e m> <x f o r m s : l a b e l>C r e d i t <x f o r m s : v a l u e>c c <x f o r m s : i n p u t r e f=”number”> <x f o r m s : l a b e l>C r e d i t Card Number: <x f o r m s : i n p u t r e f=” e x p i r y ”> <x f o r m s : l a b e l>E x p i r a t i o n D a t e : <x f o r m s : s u b m i t s u b m i s s i o n=” submit ”> <x f o r m s : l a b e l>Submit

11

te ontwikkelen die kunnen draaien op meerdere platformen. XUL hangt af van de huidige web standaarden en technologi¨en zoals CSS, JavaScript, en DOM. Hierdoor kan XUL gemakkelijk worden aangeleerd door mensen die al wat ervaring hebben in web-programmeren en -design[Wik07b]. Zoals in HTML kan je in XUL een UI cre¨eren door middel van een markup language. Bovendien heb je Cascading Style Sheets (CSS) om de looks en JavaScript om het gedrag te bepalen. XUL biedt in tegenstelling tot HTML een krachtige set van UI widgets om menu’s, toolbars, . . . te cre¨eeren[XUL07]. Dit betekent dat je niet meer moet gaan zoeken naar code of een groot stuk JavaScript code moet invoegen om enkel een pop-up menu te tonen. Bovendien zijn de elementen zo ontworpen dat ze de ‘look and feel’ hebben van een native applicatie (ondersteuning van Windows XP en MaxOS X), maar je kan CSS gebruiken om de applicatie een eigen look te geven[XUL07]. Een voorbeeld7 is te vinden in listing 2.5. Dit voorbeeld itereert over een aantal diersoorten. Voor iedere soort wordt een menulijst gemaakt. We zien dat er twee regels worden gebruikt. De eerste regel zorgt ervoor dat er een hbox wordt aangemaakt met een label. De tweede regel zorgt ervoor dat ieder dier opgehaald wordt en als een lijst wordt weergeven in de parent hbox, die aangemaakt is in de eerste regel. Omdat de template builder automatisch recursie doet, zal de tweede regel enkel effect hebben op de binnenste items. De bouw van de tweede regel vertoont veel gelijkenis met de bouw van een regel in UIML (meer informatie is te vinden in sectie 3.3.1). Het resultaat van het voorbeeld is te vinden in figuur 2.8.

Figuur 2.8: Resultaat van listing 2.5 7

http://www.xulplanet.com/testcases/example-viewer.xul

12

Listing 2.5: XUL Voorbeeld 1

2 3 4 5

6 7 8 9 10 11 12 13

14 15 16 17 18 19 20 21 22 23 24 25

< l a b e l v a l u e=” r d f : h t t p : //www. some−f i c t i t i o u s −zoo . com/ r d f #name” /> <member c o n t a i n e r=” ? u r i ” c h i l d=” ? animal ” /> < t r i p l e s u b j e c t=” ? animal ” p r e d i c a t e=” h t t p : //www. some−f i c t i t i o u s −zoo . com/ r d f#name” o b j e c t=” ?name” /> <m e n u l i s t> <menupopup> <menuitem u r i=” ? animal ” l a b e l=” ?name” />

13

2.4

Conclusie

We kunnen concluderen dat UIDL een makkelijke manier is voor het beschrijven van een UI zonder dat een ontwikkelaar veel programmeerkennis moet hebben van een UI toolkit. UIDL voldoet echter niet wanneer de ontwikkelaar te maken heeft met meerdere toolkits. Hiervoor is het gebruik van een HLUIDL een betere optie. In tabel 2.1 is een samenvatting te vinden van de UI talen die besproken zijn.

14

15

HLUIDL

HLUIDL

XUL

XForms

UIDL

HLUIDL

UIML

GladeXML

Type UIDL

XAML

Tabel 2.1: Overzicht UI talen

Abstractie Specifieke widgets (, ) Generieke elementen (<part>) Specieke elementen (<widget class=’Button’> mapt op Gtk.Button) Specifieke widgets (, <menuitem>) Specifieke widgets (<xforms:label>, <xforms:input>) Triggers koppelen

Condition / action

Condities PropertyTriggers attribute=“Functie”(bv Loaded=“PageLoaded”) Condition / action (, <equal>, <event>) Signal koppelen aan functie

Hoofdstuk 3

UIML - User Interface Markup Language 3.1

Inleiding

UI’s of gebruikersinterfaces moeten meer en meer ontwikkeld worden voor verschillende devices zoals een PDA, een computer, een smartphone, . . . . Dit is goed nieuws voor de gebruiker, want deze krijgt nu een waaier van keuzemogelijkheden. Voor de ontwikkelaar van een UI is dit echter geen lachertje, want er doen zich immers verschillende problemen voor. Hij moet verschillende technologi¨en aanleren. Enkele voorbeelden zijn Wireless Markup Language (WML) die gebruikt wordt voor mobiele telefoons en aanverwante apperaten die gebruik maken van het WAP1 protocol, C++ met specifieke structuren voor PalmOS of WindowsCE, enzovoorts. Al deze talen hebben het probleem dat ze evolueren in de tijd. Functienamen veranderen, sommige verdwijnen en nieuwe functies en klassen komen erbij. Ook de toolkits evolueren snel. Het is moeilijk voor de ontwikkelaar om deze veranderingen continue te blijven volgen. Sommige toolkits veranderen zo snel, dat het niet mogelijk is om de code telkens opnieuw aan te passen aan de nieuwere versie. Het is moeilijk voor de ontwikkelaar om de UI consistent te houden over de verschillende technologi¨en en platformen. Stel dat we een applicatie maken die op vijf verschillende platformen moet draaien. Als we ´e´en aanpassing doen, hoe klein ook, moeten we de code aanpassen voor de vijf verschillende platformen om consistent te blijven. 1

Wireless Application Protocol

16

3.2

Doel

UIML of User Interface Markup Language is een HLUIDL die toelaat om UI’s te beschrijven in XML op een abstracte, declaratieve manier. Het kan gezien worden als een meta-taal. Specieke elementen zoals <window> of zijn niet aanwezig, er wordt gebruik gemaakt van generieke elementen zoals <part> en <property>, zie figuur 3.1. Deze worden gebruikt om de interface te beschrijven. Een voorbeeld is gegeven in listing 3.1. In dit voorbeeld wordt een simpele teller beschreven met knoppen om de teller te verhogen, te verlagen en te resetten. Het voordeel van de elementen gebruikt in UIML is dat een UIML document kan gemapt worden op eender welk type van UI, van grafische tot spraak UIs en zelfs op types die nog niet zijn uitgevonden. UIML is dus voorbereid op de toekomst. Meer details over de mapping wordt uitgelegd in sectie 3.3.2.

Figuur 3.1: Het verschil tussen specifieke en generieke elementen, in dit voorbeeld tussen en <part>

3.3

Elementen

De structuur van een UIML document[AH] is getoond in figuur 3.2. Zoals te zien is, is een UIML document opgebouwd uit 4 delen: 1. Een optionele header die metadata geeft over het document. ... 2. Een element dat de UI beschrijft (zie 3.3.1) 17

Listing 3.1: UIML Voorbeeld 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

18 19 20 21

22 23 24 25 26 27 28 29 30 31

. . . < i n t e r f a c e> <s t r u c t u r e>

< s t y l e>

Counter

dec ( −)

c l e a r

i n c (+)

0 ...

. . .

18

... 3. Een element dat de mapping voorziet met de widget set (zie sectie 3.3.2) ... 4. Een optioneel element template dat het hergebruik van stukken UI code toelaat (zie sectie 3.3.3)

Figuur 3.2: Structuur van een UIML document[LVC]

3.3.1

Interface

Het interface element beschrijft de user interface en de interactie die de gebruiker met de UI kan doen. Het beschrijft echter niet de interactie van de UI met de applicatie logica. Hiervoor bestaat de tag , die wordt besproken in sectie 3.3.2. Een interface element is opgebouwd uit vier delen zoals getoond in listing 3.2. Structure Dit element bevat de bescchrijft de opbouw van de user interface. Het kan worden voorgesteld door een virtuele boom van allemaal verschillende delen 19

Listing 3.2: <structure> 1 2 3 4 5 6

<s t r u c t u r e>

of parts. Ieder part heeft minstens ´e´en attribute, namelijk de naam van de klasse dat het part moet voorstellen. De verschillende parts kunnen genest worden om zo een hi¨erarchie te cre¨eeren. Een voorbeeld is te vinden in listing 3.2. De UI is opgebouwd uit 3 parts: ’fr’ dat een instantie is van de klasse Frame, ’login’ (klasse Entry) en ’submit’ (klasse Button). ’entry’ en ’button’ zijn genest binnen ’fr’, wat betekent dat er een relatie bestaat tussen deze 3 parts. Style Dit element beschrijft de eigenschappen van de elementen die beschreven zijn in het <structure> gedeelte. Het bestaat uit een lijst van <property> elementen. Zo kan bijvoorbeeld de positie, de grootte, de zichtbaarheid, . . . bepaalt worden. Het is te vergelijken met CSS2 bij HTML. Hierin wordt namelijk ook beschreven hoe een webpagina er moet uitzien. Een voorbeeld is te zien in figuur 3.3. Hier wordt een simpel formulier aangemaakt met een label, een tekstveld en een knop. We zien dat het attribuut class bij het element <part> overeenkomt met een element in de vocabulaire (verder uitgelegd in sectie 3.3.2). Als we dan de style van een part willen defini¨eren, linken we deze met een property element via het attribuut part-name. Eens deze elementen gelinkt zijn, kunnen we in de vocabulaire gaan opzoeken welke eigenschappen we allemaal kunnen aanspreken (in dit geval ‘text’). Content Dit element bevat de tekst, afbeeldingen en andere vormen van inhoud dat in de UI zal voorkomen. Iedere waarde wordt herkend door een unieke identifier. Data kan worden aangeroepen door middel van het element. Dit element is vooral handig bij meertalige applicaties. Vaste 2

Cascading Style Sheets

20

Figuur 3.3: Style stukken tekst kunnen hier dan in de verschillende spreektalen worden gedefinieerd en naderhand worden weergegeven aan de gebruiker naargelang de geselecteerde spreektaal. Ook is dit element nuttig voor applicaties die zowel tekst aanbieden voor beginnende als gevorderde gebruikers. Behavior Wanneer de UI wordt getoond aan de gebruiker, is het uiteraard wenselijk dat deze UI ook daadwerkelijk iets doet en niet enkel statisch is. Om deze reden kan een part (zoals gezien in het <structure> element), at runtime, interageren met de gebruiker, met een ander part of met de application logic. Het element bevat een aantal regels ( elementen) 21

Listing 3.3: 1 2 3 4 5 6 7 8 9 10

<e v e n t c l a s s=” B u t t o n P r e s s e d ” part −name=” button ” /> ...

die beschrijven hoe de UI moet reageren op stimuli, komende van ofwel de gebruiker of van de applicatielogica. Stel dat een gebruiker bijvoorbeeld op een knop klikt, dan zal hiervoor een event gegenereerd worden dat kan worden opgevangen in een element. Een regel bestaat uit een conditie met een bijhorende actie. Deze actie wordt enkel uitgevoerd wanneer aan de conditie voldaan wordt. Een voorbeeld is te vinden in listing 3.3. Hier is te zien dat de actie slechts mag worden uitgevoerd wanneer er op de knop ‘button’ is geklikt. Meer uitleg is te vinden in hoofdstuk 4.

3.3.2

Peers

Onder het element bevinden zich 2 elementen, namelijk <presentation> en . Presentation Ieder UIML document bevat een vocabulaire dat de mogelijke abstractie defineert. Deze vocabulaire staat in het document zelf ofwel in een extern bestand. Er kan naar dit extern bestand gerefereerd worden door middel van het base attribute (<presentation base=‘‘http://www.example.org/swf-1.1.uiml’’>). Een vocabulaire wordt als volgt opgesteld: het <presentation> element bestaat uit ´e´en of meerdere elementen. Een element stelt een widget voor in een specifieke widget set zoals System Windows Forms. In listing 3.4 wordt een id ‘Frame’ gemapt op een System.Windows.GroupBox. Ieder widget heeft natuurlijk eigenschappen bijvoorbeeld zijn grootte, de weergegeven tekst of zijn positie op het scherm. Deze kunnen gemapt worden door een element te gebruiken. Eventuele parameters

22

Listing 3.4: <presentation> 1 2 3 4 5 6 7 8 9

10 11 12 13 14 15 16 17 18

voor deze properties kunnen worden gedefineerd door een element te gebruiken, waarin het type wordt gespecifieerd. Logic Het element beschrijft abstracties van de onderliggende applicatielaag die de UI kan gebruiken. Deze functionaliteit kan ge¨ımplementeerd zijn door middel van ´e´en of meerdere scripts in een scripting taal, door een set van objecten waarvan de methodes worden opgeroepen tijdens de gebruikersinteractie met de UI, of een combinatie van deze. Met andere woorden, dit element is de enige link tussen de UIML code en externe code. Het bestaat uit ´e´en of meerdere elementen. Zo een element geeft aan op welke klasse dit element wordt gemapt. Onder een element bevinden zich ´e´en of meerdere elementen. Deze elementen stellen de methodes voor die zich in de gemapte klasse bevinden, samen met hun return type en hun parameters met bijhorend type. In figuur 3.4 is te zien dat ‘CompactGUI’ een component bevat die mapt op de klasse ‘Uiml.FrontEnd.CompactGUI’. In deze klasse worden de volgende methodes gedefinieerd: 1. void OpenUimlFile (); 23

Figuur 3.4: Logic 2. String UimlFileName (); 3. void Render (); In de code kan deze methode dan worden aangeroepen door middel van het element. Stel dat de functie ‘OpenUimlFile’ moet worden aangeroepen nadat de gebruiker heeft geklikt op een knop, dan volstaat het om bij het element ‘GUI.Open’ aan te roepen ().

3.3.3

Templates

UIML laat toe om templates te defini¨eren. Dit zijn herbruikbare componenten die bestaan uit stukken UI code of zelfs een volledig UI op zich[AH]. Deze componenten kunnen gebruikt worden om in eender welk UIML document toe te voegen of zelfs meerdere keren in hetzelfde document. Het voordeel van templates is dat ontwikkelaars een bibliotheek van UI componenten en style sheets kunnen aanmaken[ASH+ 07]. Een template kan worden toegevoegd aan een UIML document door middel van het source attribute dat de meeste elementen bevatten. Zo kan een bijvoorbeeld een login formulier worden ingevoegd in een document dat al eerder werd gemaakt (zie listing 24

3.5). Er zijn drie mogelijke manieren om een template in te voegen, namelijk ‘replace’, ‘union’ en ‘cascade’. Listing 3.5: Template invoegen 1 2 3 4

5 6

<s t r u c t u r e>

...

25

Hoofdstuk 4

Behavior 4.1

Inleiding

Wat gebeurt er als een bepaalde conditie waar is? Met andere woorden, wat gebeurt er als de gebruiker op een knop klikt? De bedoeling is het bereiken van een interface die interageert met de gebruiker. Wanneer er een behavior (of gedrag) in het document is gespecifieerd, kan de UI interactief worden. Er kan duidelijk omschreven worden wanneer er iets moet gebeuren. Als de gebruiker op een knop klikt, dan moet een server starten bijvoorbeeld. Dit is echter niet goed genoeg. Stel, je hebt een programma waarbij de gebruiker een aantal velden kan invullen en dat het formulier enkel mag verwerkt worden wanneer alle velden ingevuld zijn. Hiervoor zijn een soort van condities nodig om te testen of alle velden wel degelijk zijn ingevuld.

4.2

Opbouw

Om gedrag te specifi¨eren moet je jezelf eerst twee vragen stellen: 1. Wat moet er gebeuren? 2. Wanneer moet dit gebeuren? De oplossingen op deze vragen zorgen ervoor dat je komt tot een regel. Deze regel omvat dus een conditie en een actie (zie figuur 4.1). In element van UIML wordt dit vertaald naar een element die een element en een bijhorend element bevat. De actie wordt enkel uitgevoerd wanneer deze conditie naar waar evauleert. Meer informatie over het evalueren van condities is te vinden in sectie 4.5. 26

Figuur 4.1: Behavior

4.3

Condities

Iedere conditie maakt deel uit van een element, hierin bevindt zich het element. In dit element kunnen, zoals de naam het al aangeeft, condities worden geschreven. In de volgende lijst staan de elementen die toegelaten zijn: equal Dit is een booleaanse expressie die evalueert naar true of false. Het kan maximum twee kinderen hebben en wordt gebruikt om te kijken of de twee kinderen tot hetzelfde resultaat of dezelfde waarde komen. event Dit event kan op twee verschillende manieren gebruikt worden. Ten eerste als test binnen , de bijhorende actie wordt dan uitgevoerd wanneer dit event plaatsvindt. Ten tweede in het element, het event wordt dan getriggerd wanneer aan de bijhorende conditie voldaan werd. op Het element zorgt ervoor dat er meer complexere structuren gemaakt kunnen worden. Verdere uitleg wordt gegeven in de volgende sectie.

4.4

Op

Voorlopig hebben we enkel besproken dat je onder het element slechts ´e´en conditie kon zetten die naar true moest evalueren, het meest gebruikte was dan een <event> element. In de vorige sectie (zie sectie 27

4.3) zagen we dat je met <equal> al een iets complexere structuur kan maken. Het nadeel van dit element is dat het maximaal twee elementen mag bevatten. Een element heeft deze beperking niet. Je kan zoveel elementen als je wilt hieronder plaatsen. Bovendien bestaat de mogelijkheid om elementen willekeurig diep te nesten (zie figuur 4.2). Hierdoor kan je een complexe situatie opvangen met slechts ´e´en conditie. Het enige dat verplicht is, is het aangeven welke operatie je wilt toepassen door middel van het attribuut ‘name’. Er is keuze uit 6 verschillende operaties en deze zijn te vinden in tabel 4.1.

Figuur 4.2: Willekeurig diep nesten

4.5

Evaluatie van condities

Condities worden ge¨evalueerd volgens een string waarde. Als je bijvoorbeeld een equal operatie hebt, dan worden deze string waarden vergeleken om te

28

Naam equal notequal and or lessthan greaterthan

Operatie == != && || < >

Defintie A == B Geeft true als A gelijk is aan B A != B Geeft true terug als A NIET gelijk is aan B A && B Geeft true terug als en slechts als zowel A als B true zijn A || B Geeft true als ofwel A ofwel B true is A < B Geeft true terug als A kleiner is dan B A > B Geeft true terug als A groter is dan B

Tabel 4.1: Operaties van [AH] Listing 4.1: Equal && Op 1 2 3 4 5 6

kijken of ze exact hetzelfde zijn. Het voorbeeld in listing 4.1 geeft een operatie weer, waarbij twee waarden met elkaar worden vergeleken. Als er een event ge¨evalueerd moet worden, dan wordt niet de string waarde genomen, maar wordt er een true of false waarde genomen naargelang dit event was opgevangen of niet. In listing 4.2 wordt het vorige voorbeeld uitgebreid. De actie behorende bij deze conditie wordt slechts uitgevoerd wanneer er ook nog eens op een knop wordt geklikt. Hier wordt ineens gebruikt gemaakt van de eigenschap dat elementen genest kunnen worden. Deze elementen resulteren ook in true of false. Bij het berekenen wordt deze boolean dan ook gebruikt om te kijken of de conditie in zijn geheel naar true of false evalueert.

Listing 4.2: Geneste 1 2 3 4 5 6 7 8 9

<e v e n t c l a s s=” b u t t o n C l i c k e d ” part −name=” c i t y ” />

29

Hoofdstuk 5

UIML.NET 5.1

Inleiding

Uiml.NET is een open source UIML renderer voor het .NET platform, geschreven in C#. Het is ontwikkeld door Kris Luyten 1 en Jo Vermeulen 2 , beide werkzaam op het Expertise Centrum voor Digitale Media (EDM3 ). In plaats van een UIML compiler werd er gekozen voor een UIML renderer. Dit is moeilijker en complexer, maar het is uiteindelijk meer flexibel. Wanneer het UIML document wordt gecompileerd, wordt het omgezet naar broncode, die op zijn beurt gecompileerd moet worden. Het transformeren van een UIML document in programma code heeft is enkel voordelig wanneer de code naderhand nog moet worden aangepast. Het renderen daarentegen is meer flexibel omdat je zo vlug een prototype kan maken dat direct getest kan worden. Bovendien biedt het dynamische veranderingen aan in de UI en een transparant mechanisme voor het connecteren van de gerenderde UI en de applicatie logica[LC]. De renderer zal de UIML code die in het document staat interpreteren en enkel tonen op het scherm indien deze aan de regels van een geldig UIML document voldoet.

5.2

Architectuur[LTVC]

Het renderen van een UIML document gebeurt in drie stappen: pre-processing, main processing en post-processing. 1

[email protected] [email protected] 3 http://www.edm.uhasselt.be 2

30

Pre-processing Tijdens deze stap zal een UIML document worden omgevormd tot een ander UIML document. Enkele voorbeelden zijn het toepassen van layout beperkingen en aanpassing aan een gebruikersprofiel. Main processing Tijdens deze stap wordt het UIML document ge¨ınterpreteerd en wordt een concrete instantie opgebouwd als een boomstructuur met de beschikbare widget set. Post-processing Tijdens deze stap wordt de concrete instantie die aangemaakt is tijdens de main processing gemanipuleerd. Een voorbeeld hiervan is het binden van de UI met de applicatie logica. We zijn vooral ge¨ınteresseerd in main processing. Hierin wordt de concrete instantie opgebouwd. Dit gebeurt in vijf stappen: 1. De UIML renderer neemt een UIML document als input, en zoekt de correcte rendering backend bibliotheek waar in het UIML document naar verwezen wordt 2. Een interne representatie van het UIML document wordt opgebouwd. Ieder part element van het document wordt verwerkt om een boom van abstracte interface componenten op te bouwen. 3. Voor ieder part element wordt de overeenkomstige style toegepast die in het document staat. 4. Voor ieder part element wordt het overeenkomstige gedrag (behavior) gekoppeld en de vereiste bibliotheken voor het gedrag worden just-intime geladen. 5. De gegenereerde boom wordt overgedragen aan de rendering module. Voor ieder part element wordt een overeenkomstig concreet widget geladen volgens de mapping die gedefinieerd is in de vocabulaire en wordt gelinkt met de interne respresentatie. Voor het gegenereerde concrete widget worden de gerelateerde style eigenschappen opgehaald en gemapt door de vocabulaire naar concrete widget eigenschappen. Hierna worden ze toegepast op het concrete widget. In stap 4 wordt ieder part element gekoppeld met zijn overeenkomstige gedrag. Dit gebeurt via reflectie. De rendering engine weet namelijk niet wat de concrete widgets zijn. Het enige dat ter beschikking is, is de vocabulaire. 31

Door het gebruik van reflectie kunnen we instanties van klasses aanmaken door enkel het kennen van de naam. Indien reflectie niet gebruikt zou worden, hebben we een ad-hoc mapping nodig. Dit limiteert de rekbaarheid van de UIML vocabulaire, als een nieuwe mapping in de vocabulaire wordt ingevoegd, zou de volledige kern ge¨ update moeten worden. Dit is niet nodig met reflectie.

5.3

Backends

UIML.NET bevat ´e´en rendering kern, maar meerdere rendering backends. Momenteel worden volgende backends ondersteund: • System.Windows.Forms • Compact SWF • GTK# • Wx.net (klein deel) • Qt# (klein deel) De backends hebben een beperkte rol. Zij verwerken enkel dingen die speciefiek zijn voor een bepaalde widget set. De rest wordt allemaal afgehandeld in de kern.

5.4

Huidige implementatie van condities

Momenteel wordt enkel het <event> element ondersteund voor condities. Dit element laat toe een bepaald event te koppelen aan een widget. Na het plaatsvinden van dit event wordt de bijhorende actie opgeroepen. Als voorbeeld kunnen we een knop nemen. Aan deze knop kan een event ‘ButtonClicked’ worden gekoppeld. De koppeling gebeurt volledig via reflectie. Wanneer een event gelinkt moet worden, wordt er een delegate aangemaakt die een functie bevat die wordt opgeroepen wanneer het event plaatsvindt. Een delegate kan vergeleken worden met een functie pointer in C of C++. Het biedt de mogelijkheid om extra parameters in een functie te encapsuleren. Een delegate is een ‘closure’, het heeft toegang tot de omliggende variabelen en functies. Een voorbeeld is te zien in listing 5.1. We

32

Listing 5.1: Delegate Voorbeeld 1

using System ;

2 3

delegate void P r i n t ( s t r i n g s ) ;

4 5 6 7 8 9 10

c l a s s Foo { s t a t i c void D i s p l a y ( s t r i n g s ) { C o n s o l e . WriteLine ( s ) ; }

11

public s t a t i c void Main ( ) { Print p = Display ; p( ” Hallo wereld ! ” ) ; }

12 13 14 15 16 17

}

zien hier dat de statische functie Display wordt gekoppeld aan de delegate Print. Als we dan de regel p("Hallo wereld!"); uitvoeren, wordt de functie Display aangeroepen met als parameter "Hallo wereld!". Deze wordt dan in de console weergegeven. Iedere backend heeft zijn eigen implementatie voor het linken van de events. Een schematische voorstelling van de huidige implementatie is te vinden in de figuur 5.1. Als er op een knop geklikt wordt, dan zal de functie Execute worden aangeroepen die via een delegate is gekoppeld. Deze functie zorgt er dan voor dat de bijhorende actie wordt uitgevoerd. Het <event> element is niet het enige element dat in een conditie kan voorkomen. Zo hebben we ook nog <equal> en (zie sectie 4.3). Deze elementen worden echter nog niet ondersteund door de huidige implementatie van UIML.NET.

33

Figuur 5.1: Werking van een gekoppelde delegate

34

Hoofdstuk 6

Implementatie 6.1

Inleiding

De bedoeling van deze thesis is het implementeren van conditionele testen. Het schrijven van de code hiervoor bracht enkele problemen met zich mee. Deze zijn uitgelegd in de volgende sectie.

6.2

Problemen

Het implementeren van condities is niet zo gemakkelijk als het lijkt. Je hebt namelijk twee soorten. De eerste soort zijn de condities die worden opgevangen door een event. Wanneer dit event dan getriggered wordt, kan in de code de conditie worden nagekeken. De tweede soort zijn condities waarvoor geen event wordt uitgestuurd. Als er bijvoorbeeld enkel getest wordt of een property een bepaalde waarde heeft, dan moet er een manier worden bedacht om dit op een of andere manier op te vangen. We weten niet exact wanneer een bepaalde waarde van een property verandert. Het probleem met de huidige implementatie bestaat erin dat er een algemene eventhandler wordt gekoppeld aan een widget per conditie. Zodra het event is getriggered wordt de actie, behorende bij de conditie, uitgevoerd. Bij condities is het echter toegelaten dat verschillende condities ge¨ınteresseerd zijn in hetzelfde event, maar komende van een verschillend widget. Een conditie kan bijvoorbeeld interesse hebben voor een klik op knop A en het checked zijn van checkbox B, terwijl een andere conditie interesse heeft voor een druk op knop A en het geselecteerde item van combobox C moet 1 zijn. Beide condities zijn ge¨ınteresseerd in een ‘ButtonPressed’ event van knop 35

A. Met andere woorden, het is niet meer mogelijk om het event (in dit geval ‘ButtonPressed’) te koppelen aan de actie van ´e´en regel omdat er twee condities graag verwittigd zouden worden van dit event. De naam van het event dat juist is getriggerd en het part die het heeft getriggered moeten worden opgevangen en bijgehouden in een globale tabel voor een aantal seconden omdat meerdere condities hierin ge¨ınteresseerd kunnen zijn. Het is niet gemakkelijk omdat je slechts een eventhandler kan koppelen aan een bepaalde functie. Op deze manier weet de ontwikkelaar normaal aan welk widget hij deze functie koppelt, maar in de huidige implementatie wordt via reflectie alles gekoppeld aan ´e´en functie per conditie. Hoe geven we de naam van het event dat juist getriggered is en de naam van het widget door? Een mogelijkheid bestaat erin de klasse ‘EventArgs’ te gebruiken. Deze wordt namelijk als een parameter meegegeven aan de eventhandler. Er duikt echter een probleem op als we deze mogelijkheid volgen. De ‘EventArgs’ klasse is een basis klasse waarvan andere kunnen afgeleid worden (voorbeelden hiervan zijn ‘MouseEventArgs’ en ‘KeyPressEventArgs’). De afgeleide klasses bevatten extra informatie die voor het bijhorende event nuttig zijn. Zoals al gezegd is, worden events opgevangen in een algemene eventhandler. Deze eventhandler krijgt de basis klasse ‘EventArgs’ mee zodat alle soorten kunnen opgevangen worden. Een oplossing voor dit probleem zal verder behandeld worden in sectie 6.3.1.

6.2.1

Kijken naar events

Spying is een methode om te kijken welke events er hebben plaatsgevonden. Het werkt met speciale ‘SpyEventArgs’, een klasse afgeleid van ‘EventArgs’. Hierin kunnen eender welke parameters worden meegegeven die nodig zijn voor de ontwikkelaar. Er wordt dynamisch een functie aangemaakt die een bepaald event opvangt. Hierdoor kunnen we zelf een eigen gemaakte functie aanroepen wanneer er een bepaald event plaats vindt. Hoe we dynamisch code bijschrijven zal nu worden uitgelegd. IlGenerator IlGenerator1 is een klasse van het .NET framework die ondersteund wordt vanaf versie 1.1. Het kan Microsoft Intermediate Language (MSIL) instructies genereren. Met deze klasse is het dus mogelijk om at runtime code bij te 1

http://msdn2.microsoft.com/en-us/library/system.reflection.emit.ilgenerator.aspx

36

schrijven die niet op voorhand kan worden geschreven. Op deze manier kunnen events worden overschreven zodat deze een bepaalde functie aanroept bij wijziging en zelfs extra parameters mee geeft aan deze functie. Een code voorbeeld is te vinden in listing 6.1. Als eerste wordt een methode met de naam ReportEvent opgehaald in de klasse SWFEventLink. Hierna wordt een methode van een eventhandler (nl Invoke) opgehaald. Om de functie ook daadwerkelijk aan te roepen worden alle parameters types opgeslagen in een tabel (methodPars). Vervolgens wordt de naam van de functie gegenereerd en wordt er een methode aangemaakt. Als laatste wordt de body ingevuld door rechtstreeks byte code te schrijven. Door middel van de functie Emit worden rechtstreeks instructies in de MSIL stream van instructies geschreven. OpCodes representeren velden van de MSIL instructies. Ldarg 0 zal argument 0 op de stack laden. Wat deze code in feite voorstelt is het schrijven van de regel ‘spy.ReportEvent("EventName", o, e)’ waarbij o de zender is en e de argumenten. Deze methode is heel effectief en heeft weinig tot zelfs geen overhead, er worden niet onnodig functies aangeroepen. Maar ILGenerator verbruikt veel resources voor at runtime code te genereren, waardoor de namespace waarin deze klasse zich bevind (System.Reflection.Emit) niet ondersteund wordt op het .NET Compact Framework. Bovendien zal dit niet werken om wijzigingen van properties op te vangen omdat de spying klasse enkel een functie zal aanroepen als een event is uitgestuurd. Een uitbreiding kan echter gemaakt worden zodat deze ook de properties overschrijft. Telkens een property wordt gewijzigd kan dan een bepaalde functie worden aangeroepen.

6.2.2

Event uitsturen

Nieuw in .NET 2.0 is de interface INotifyPropertyChanged. Met deze interface kan je gemakkelijk een event uitsturen wanneer een property wijzigt. Het doet eigenlijk min of meer hetzelfde als custom events schrijven. Dus het nadeel is onmiddellijk duidelijk, je moet zelf de functie NotifyPropertyChanged(string property); aanroepen. Dit is niet mogelijk aangezien we tijdens het schrijven van de code niets weten over de property waarin de ontwikkelaar van de UI ge¨ınteresseerd is.

6.2.3

Kijken of een property verandert

Een manier om te kijken of een waarde van een property is verandert, is om de x milliseconden te pollen. Dit wil zeggen dat er iedere x milliseconden 37

Listing 6.1: ILGenerator Voorbeeld 1

MethodInfo miReportEvent = typeof ( SWFEventLink ) . GetMethod ( ” ReportEvent ” ) ;

2 3 4 5

MethodInfo i n v o k e = typeof ( EventHandler ) . GetMethod ( ” I nvo ke ” ) ; P a r a m e t e r I n f o [ ] p a r s = i n v o k e . GetParameters ( ) ; i n t l e n = p a r s . Length ;

6 7 8 9 10 11 12

// Haal de parameter l i j s t op Type [ ] methodPars = new Type [ l e n ] ; f o r ( i n t i = 0 ; i < l e n ; i ++) { methodPars [ i ] = p a r s [ i ] . ParameterType ; }

13 14 15

// Maak e v e n t naam bv ’ C l i c k ’ wordt ’ OnClick ’ S t r i n g methodName = ”On” + e I n f o . Name ;

16 17 18

// Maak een method MethodBuilder method = t h e C l a s s . DefineMethod ( methodName , M e t h o d A t t r i b u t e s . P u b l i c , typeof ( void ) , methodPars ) ;

19 20 21 22 23 24 25 26 27 28

// S c h r i j f de method body I L G e n e r a t o r i l = method . GetILGenerator ( ) ; i l . Emit ( OpCodes . Ldarg 0 ) ; i l . Emit ( OpCodes . Ldfld , f l d ) ; i l . Emit ( OpCodes . Ldstr , e I n f o . Name) ; i l . Emit ( OpCodes . Ldarg 1 ) ; i l . Emit ( OpCodes . Ldarg 2 ) ; i l . Emit ( OpCodes . C a l l v i r t , miReportEvent ) ; i l . Emit ( OpCodes . Ret ) ;

29 30 31

// Voeg de nieuw gemaakte e v e n t h a n d l e r t o e e I n f o . AddEventHandler ( t a r g e t O b j e c t , D e l e g a t e . C r e a t e D e l e g a t e ( e I n f o . EventHandlerType , impl , ”On” + e I n f o . Name) ) ;

38

Figuur 6.1: Polling een stuk code wordt opgeroepen. Het is dan de bedoeling om alle condities af te gaan. Voor iedere conditie moet dan gekeken worden of alles evalueert naar waar. Het probleem met polling bestaat erin dat er nogal wat overhead geproduceert wordt, zeker als de user interface een moment idle is. Want dan wordt nog altijd gepold. Polling is dus niet geschikt om te werken op toestellen die zuinig moeten omspringen met hun resources, zoals een smartphone of een PDA. Er zou teveel van de batterij van deze toestellen gevraagd worden. Er moet een manier gevonden worden om polling te vermijden. Met andere woorden, er moet iets gevonden worden waardoor je een property van een widget kan volgen. Wanneer er iets verandert aan die property, zou dit een event moeten uitsturen. Dit event kan dan worden opgevangen, en de nodige condities kunnen getest worden.

6.3

Condition manager

We zitten nog altijd met vraag: Hoe vangen we de wijziging van een property van een widget op? De idee is dat bij iedere verandering van staat van een widget, alle condities opnieuw moeten bekeken worden om te zien of er door deze wijziging een conditie evalueert. Mijn implementatie zorgt er dan ook voor dat alle condities worden ondergebracht in ´e´en object. In dit object worden ook alle events afgehandeld. Waarom er wordt gewerkt met een manager wordt uitgelegd in sectie 6.3.3. Hierin bevindt zich ook de globale tabel waarover gesproken is in sectie 6.2. In de rest van deze paragraaf zal eerst besproken worden hoe de events nu worden opgevangen om daarna verder te gaan met het opvangen van de property wijzigen. 39

Listing 6.2: Wrapper rond een event handler 1

2 3 4 5 6 7 8

v i r t u a l public EventHandler CreateHandlerWrapper ( s t r i n g concreteEventName , s t r i n g partName ) { return delegate ( object s e n d e r , EventArgs e ) { Execute ( s e n d e r , e , concreteEventName , partName ) ; }; }

6.3.1

Anonieme delegates

Om te weten welk event juist getriggered is, wordt er gebruik gemaakt van anonieme delegates. Wat een delegate precies is, werd al uitgelegd in sectie 5.4. Een anonieme delegate is een functie zonder een naam. Hierdoor wordt de code gereduceerd doordat er geen aparte functie moet worden aangemaakt. In listing 6.2 is een code voorbeeld te zien van de wrapper die gebruikt wordt. In dit voorbeeld is te zien dat er anonieme delegate wordt aangemaakt. Er wordt namelijk een functie teruggegeven. Als de wrapper wordt gekoppeld aan een object, bevat het twee extra parameters die werden meegegeven bij het aanmaken van de wrapper, namelijk ‘concreteEventName’ die de naam van het event geeft dat juist getriggered werd en ‘partName’ die een identifier is voor het object dat in het event ge¨ınteresseerd is. Wanneer het desbetreffende event nu tijdens het runnen van de code wordt aangeroepen, bevat het deze twee extra parameters.

6.3.2

De linker

Hoe vangen we nu wijzigingen van een property op? Als de ontwikkelaar ge¨ınteresseerd is in het aanvinken van checkbox A, dan worden alle events van checkbox A geregistreerd in de linker via reflectie. Wanneer ´e´en van deze events zich voordoet, dan weten we dat er iets verandert is aan die checkbox. Het enige dat we dan nog moeten doen, is kijken of de conditie evalueert naar waar. Het registeren van alle events zorgt natuurlijk voor heel wat overhead, de condities worden vaak gecheckt op momenten wanneer het niet nodig is. Maar er blijft een voordeel ten opzichte van polling. Wanneer een interface idle is, zal er ook niets gecheckt worden. Alles blijft stil totdat de gebruiker beslist om terug te werken met de interface. De rest van de linker blijft hetzelfde. Als we een <event> element tegenkomen, wordt dit 40

via reflectie aan het desbetreffende object (widget) gekoppeld. Het linken van een conditie gebeurt nu niet langer meer in de backends, maar is verplaatst naar de kern. Er zijn twee interfaces, namelijk IEventLinker en IEventLink waarvan de volgende klasses zijn afgeleid (zie ook figuur 6.2): EventLinker is afgeleid van IEventLinker en zorgt voor het linken van een conditie. Hiervoor gebruikt hij de klasse ConditionLinker die alles afhandelt. EventLink is afgeleid van IEventLink en zorgt voor het nakijken of een conditie evalueert naar waar. Hij gebruikt hiervoor de klasse ConditionChecker. Tijdens het linken wordt iedere conditie opgeslagen in de condition manager (klasse ConditionManager), die nu verder besproken zal worden.

Figuur 6.2: Het linken en checken van events Doordat het linken nu in de core gebeurt en niet meer in de backends is 1/3 van de klasses uit de backends verdwenen. Met andere woorden, de backends hebben minder verantwoordelijkheden gekregen.

41

Listing 6.3: Execute functie 1

2 3 4

public void Execute ( Obje ct s e n d e r , EventArgs e , s t r i n g eventName , s t r i n g partName ) { C h e c k E v e n t s I n t e r e s t e d ( eventName , partName ) ; }

6.3.3

De manager

De manager is een klasse die alle events opvangt en afhandelt. Het bevat alle condities van de volledige interface. Wanneer een event getriggered wordt, dan zal een centrale functie in deze klasse aangeroepen worden. Dit is de functie te vinden in listing 6.3, zie ook figuur 6.3. Deze functie heeft 2 extra parameters zoals besproken in sectie 6.3.1. Het event dat zich juist heeft voorgedaan, wordt in een tabel geplaatst, waar het een bepaald aantal seconden zal worden bijgehouden. In mijn implementatie is dit 5 seconden. Dit is nodig omdat er conditions ge¨ınteresseerd kunnen zijn in ´e´en of meerdere events. Door ze bij te houden in een tabel, kunnen altijd de events worden opgevraagd die de afgelopen seconden zijn gebeurt. Vervolgens worden alle condities afgegaan. Voor iedere conditie wordt gekeken of het aan de voorwaarden voldoet. Hiervoor is de functie CheckCondition() ge¨ımplementeerd. Deze functie loopt alle voorwaarden van de conditie af en kijkt of deze evauleren naar waar (regels voor evaluatie zijn besproken in sectie 4.5). Er wordt ook een boolean bijgehouden om aan te geven of de actie, horende bij de conditie al is uitgevoerd. Anders zou deze actie meerdere keren worden uitgevoerd. De boolean wordt gereset wanneer de conditie evauleert naar niet waar.

42

Figuur 6.3: Het plaatsvinden van een event

43

Hoofdstuk 7

Uitgebreid voorbeeld In dit hoofdstuk wordt een volledig uitgewerkt voorbeeld gegeven van het gebruik van condities. Het voorbeeld is te vinden in bijlage A en stelt een registratieformulier voor. In dit formulier is het verplicht om alle velden in te vullen om je te kunnen registreren. Indien deze velden niet zijn ingevuld en er wordt op de knop ’send’ gedrukt, dan wordt er een gepaste foutboodschap gegeven. In het <structure> element (zie listing 7.1) zien we dat er een container wordt aangemaakt waarin verschillende widgets zullen gepositioneerd worden. Deze widgets zijn labels met elk een bijhorend invoerveld, zoals bijvoorbeeld l firstName, wat een label voorstelt met de tekst ‘First name:’ en het bijhorende invoerveld firstName (zie figuur 7.1). Er worden ook twee knoppen aangemaakt. Deze knoppen dienen voor het leegmaken van het formulier (reset knop) en het versturen van het formulier (send knop). Listing 7.1: <structure> element ... <s t r u c t u r e>

44

...

In het <style> element (zie listing 7.2) worden de widgets van tekst voorzien en op een goede plaats in de UI gezet. Zie bijlage A. We hebben nu een volledige UI gedefinieerd. Het enige wat nog ontbreekt is de interactie met de gebruiker. Er staan twee knoppen in de UI, die niets doen wanneer de gebruiker er op klikt. We komen dus bij het element. Als we kijken naar het voorbeeld zien we dat er in totaal drie regels zijn. Listing 7.2: <style> element ... < s t y l e> < !−− C o n t a i n e r −−>

5 0 0 , 5 0 0 < !−− L a b e l f i r s t n a m e −−>

Voornaam:

8 0 , 1 5

1 0 , 1 5 ... ...

1. De eerste regel (zie listing 7.3) zorgt ervoor dat wanneer de gebruiker klikt op de knop met de tekst ‘reset’ dat alle velden worden leeggemaakt door in ieder veld een lege string te plaatsen. 2. De tweede regel (zie listing 7.4) gaat kijken of alle velden zijn ingevuld. Er is een mechanisme nodig om te kijken of ieder veld verschillend is van een lege string. Hiervoor dienen de binnenste elementen. In figuur 7.2 is een deel van de code gegeven. Dit stuk code kijkt of het veld firstName verschillend is van een lege constante waarde (de lege string). Om er zeker van te zijn dat ieder veld ingevuld is, moeten we de binnenste elementen in een element plaatsen met als attribuut name=‘‘and". ‘‘and" wil zeggen dat ieder elementen moet evalueren naar waar. Nu hebben we bijna onze conditie samengesteld. Het enige dat nog mist, is een event zodat er ook op de knop met de tekst ‘send’ geklikt kan worden. Als we dit event nog toevoegen samen met een extra element (dezelfde reden als eerder) komen tot de volledige conditie.

45

3. De derde en laatste regel (zie listing 7.5) gaat kijken of er ´e´en of meerdere velden niet zijn ingevuld. Er wordt dan een gepaste boodschap op het scherm getoond. Er moet nu exact het omgekeerde gedaan worden van regel 2. Listing 7.3: Het leegmaken van het formulier ... <e v e n t part −name=” r e s e t ” c l a s s=” B u t t o n P r e s s e d ” />

...

Listing 7.4: Kijk of alle velden zijn ingevuld ... <e v e n t part −name=” send ” c l a s s=” B u t t o n P r e s s e d ” />

... < c a l l name=”Box . Show”> <param>S u c c e s v o l g e r e g i s t r e e r d ...

46

Listing 7.5: Kijk of er ´e´en of meerdere velden niet zijn ingevuld ... <e v e n t part −name=” send ” c l a s s=” B u t t o n P r e s s e d ” />

... < c a l l name=”Box . Show”> <param>A l l e v e l d e n z i j n v e r p l i c h t ! ! ...

Regel 2 en 3 zijn noodzakelijk, ook al lijken ze sterk op elkaar. Het zou beter zijn als we deze twee regels konden combineren in ´e´en regel. Op het eerste zicht zouden we de elementen <when-true> en <when-false> kunnen gebruiken. Om tot hetzelfde resultaat te komen, hebben we echter een extra test nodig in deze elementen. Volgens de specificatie lijkt dit mogelijk te zijn, maar de praktijk wijst zich anders uit. De UIML standaard moet dus eerst verder uitgebreid en/of aangepast worden. Een andere mogelijkheid is templates te gebruiken. We kunnen dan van een element een template maken omdat de twee regels enkel verschillen in het gebruik van “and” in plaats van “or”, “equal” in plaats van “notequal” en ze geven elk een andere boodschap weer. Op deze manier kunnen we dit stukje UIML code hergebruiken. In listing 7.6 is het voorbeeld herwerkt. Listing 7.6: Het gebruik van templates om de regels te combineren ...