XUL och XAML

För att på ett enhetligt sätt kunna skapa gränssnitt har Mozilla utvecklat ett språk som kallas XML User Interface Language, eller XUL. I XUL har flera välbeprövade standarder, som bland annat XSLT, XPath och DOM, använts för att manipulera gränssnittet samtidigt som XML beskriver gränssnittet (XULPlanet.com 2006, What is XUL?). Fördelen med XUL är enligt Jons- son (2006) att det ger ett robust ramverk för användargränssnitt och ifall

5.5. ALTERNATIVA LÖSNINGAR KAPITEL 5. AJAX

webbläsare har stöd för XUL kan applikationer startas i webbläsaren med samma grafiska gränssnitt som andra lokala program. Tack vare att XUL använder JavaScript har man tillgång till XMLHttpRequest-objektet vilket då gör att sidan kan uppdateras på samma sätt som AJAX för webbsidor. Nackdelen med XUL är enligt Jonsson (2006) att det har stöd av endast ett fåtal webbläsare.

Med .NET version 3.0 introducerades en rad nya teknologier och en av dessa var Extensible Application Markup Language, eller XAML. XAML beskrivs enligt XAML.NET (2005) som följer:

XAML is a declarative XML-based language that defines objects and their properties in XML. XAML syntax focuses upon defining the UI (user in- terface) for the Windows Presentation Foundation (WPF) and is therefore separate from the application code behind it.(XAML.NET 2005, What is XAML?)

Principen är densamma som i XUL, det vill säga att med hjälp av ett plattformsoberoende språk beskriva uppbyggnaden av ett grafiskt gränssnitt. XAML.NET (2005) påpekar också att även om XAML i första hand är ut- vecklat för Microsoft Windows så kan språket komma att kunna användas även på andra plattformar. Fördelen med XAML är att hela applikationer kan skrivas i samma programmeringsspråk samtidigt som nackdelen är att språket inte är fullständigt utvecklat utan kommer vara av betydelse först om något år.(Jonsson 2006, s. 10).

Kapitel 6

Analys

Nedan följer en analys av JDP och framför allt det som rör webbapplika- tionslagret i ramverket. Vilka är problemen och varför? Hur kan problemen lösas och varför löses problemen?

Eftersom man sett fördelarna som AJAX kan tillföra ramverket kommer även en utredning göras av hur denna integrering ska kunna göras och vad som bör tänkas på, för- och nackdelas samt hur andra ramverk behandlar liknande integrering.

6.1

Modell av webbapplikationen

Det största problemet med ramverket är modelleringen av webbapplikatio- nen. Hela idén med ramverket är att undvika tidsödande kodskrivning ge- nom att beskriva systemet med hjälp av en modell. Detta misslyckas när det kommer till webbapplikationen. Här modelleras implementationen till Struts Action-klasser med stereotyper och andra märkningar för att indikera vad som är Action-klasser och vad som är ActionForm-klasser samt arv och as- sociationer för att indikera sidflöden. I princip modelleras kod, det vill säga man modellerar hur något ska göras istället för vad som ska göras. Detta ger ett system som är svårt att underhålla, webbapplikationen blir hårt bunden till Struts och ger en väldigt statisk arkitektur. Dessutom måste utvecklaren inte bara känna till hur JDP fungerar utan även Struts när det kommer till Action-klasserna. Om man skulle vilja byta ut Struts mot någon annan tek- nologi så måste inte bara nya mallar utvecklas utan diagrammen måste även ritas om från grunden. Det skulle kräva någon annan form av modell eller något annat koncept att modellera.

Idag existerar ett antal modelleringsverktyg och specifikationer för hur webbapplikationer ska kunna modelleras, exempelvis Web Modeling Lan-

6.1. MODELL AV WEBBAPPLIKATIONEN KAPITEL 6. ANALYS

guage och UML-based Web Engineering, men ingen officiell standard finns framtagen. Ett alternativ kan vara att modellera tjänster som är specifika för webbapplikationer likt de som redan idag modelleras i tjänstelagret. Dessa tjänster kan då exponeras i form av JavaScript och den som utvecklar webb- sidorna kan välja att anropa tjänsterna och med hjälp av AJAX presentera resultatet. Detta ger också en ännu tydligare separation mellan systemets kärna och representationen av densamma.

Genom att modellera tjänster specifika för webbapplikationen, likt de som i JDP-ramverket kommunicerar med domänlagret, kan kod genereras dels för tjänsterna i form av Java-klasser och dels för konfiguration för att exponera tjänsten via URL-mappning likt sättet som Struts Action-klassernas expo- neras idag. Dessutom kan JavaScript-filer genereras åt webbsideutvecklaren så denne enkelt kan anropa tjänsterna genom att helt enkelt anropa genere- rade JavaScript-funktioner. I och med att tjänsterna alltid har ett gränssnitt kan grundläggande validering tillhandahållas per automatik där framförallt metodargumenten kan valideras i form av antal och typ innan de anropas.

Hur skulle det se ut att fortsätta använda Struts på samma sätt som det används idag? Faktum är att det inte är något fel på Struts som gör det svårt att arbeta med. Det skulle gå att fortsätta använda ramverket på samma sätt som i dagsläget utan problem. Däremot om man i framtiden vill byta ut Struts mot en nyare version eller ett helt nytt ramverk blir de modellerna som är ritade för webbapplikationslagret odugliga. Detta på grund av att modellerna är en ren avbildning av den kod som senare genereras; modellen är alltså ritad källkod. Istället för att då modellera hur applikationen ska uppföra sig så bör modellen beskriva vad som ska göras.

Ytterligare ett stort problem som existerar vid modellering av webbappli- kationen är hur interaktionen mellan användaren och systemet modelleras. Idag sker detta genom att associationer märks med stereotyper samt ett namn specifikt för Struts och detta länkas ihop med hjälp av Action-klasser. När användaren utför en handling, till exempel skickar iväg ett formulär, beror det på namnet på associationen vart användaren kommer vidarebefodras. Detta gör systemet inte bara svårunderhållet utan även statiskt och svårförstått eftersom diagrammet inte säger någonting om hur navigeringen fortskrider. För utvecklarens del är problemet att denne med hjälp av en sträng måste tala om hur användaren ska vidarebefodras vilket lätt ger fel vid körning av applikationen istället för vid kompilering om fel sträng har angivits. Om flödet ska modelleras enligt den traditionella sidbaserade modellen krävs att varje sida har ett in- och ett utgränssnitt. Därför bör sidorna först modelleras i diagram där dess gränssnitt beskrivs och i ett annat diagram binds sidorna ihop med matchande in- och utgränssnitt.