Inledning
Nu när det finns en första "Hello, World"-version av Eats-o-matic i drift, är det dags att fundera på allvar på den vidare utvecklingen.
För att det skall bli något så behövs det bland annat möjlighet att lagra data, samt ett ramverk för att skapa själva webbapplikationen med.
Jag har kollat igenom ett antal av de alternativ som finns för GAE och kommit fram till ett val som jag tror passar mig som utvecklare och Eats-o-matic som applikation.
Persistens
Vi tar det enkla beslutet först, val av persistensmekanism.
GAE erbjuder två programmeringsgränssnitt för att lagra data: Java Data Objects (JDO ) och Java Persistence Architecture (JPA). (Egentligen finns det ett tredje, lågnivågränssnittet mot Googles egna Big Tables. Men detta tänker jag inte ens beakta, för då har man låst sig hårt mot GAE:s driftsmiljö, vilket bär mig emot.)
JDO är en ganska gammal och beprövad standard, medan JPA är tämligen färskt. Varför JDO inte har fått större spridning förstår jag faktiskt inte. Det passar utmärkt för en stor mängd av tillämpningar. Det är heller ingen brist på effektiva, billiga och stabila implementationer.
(Vissa elaka tungor i blogosfären säger att Sun tog fram JPA efter starka påtryckningar från de ledande RDBMS-leverantörerna, vars produkter inte fungerar så bra med JDO.)
JDO togs ursprungligen fram som ett standard-API för att lagra data i stort sett vilket medium som helst, medan JPA mer eller mindre förutsätter att datat skall lagras i en relationsdatabas.
I GAE så hamnar datat i bägge fallen i BigTable, som varken är en objektdatabas eller en relationsdatabas.
I GAE så används i bägge fallen DataNucleus som verktyg för att vid byggtillfället modifiera dina persistenta klasser så att de går att lagra. Så valet mellan JDO och JPA avgörs av vilket API som passar applikationen bäst.
Jag har jobbat en del med JPA och Hibernate och MySQL, vilket inte var helt friktionsfritt. Det märks att objekt inte är rader i en tabell, utom i det mest triviala fallet. (Jag har lusläst Hibernatedokumentationen flera gånger, och är fortfarande inte säker på att jag förstår allt som står där…)
Jag har även jobbat med db4o, vilket var betydligt mer rättframt. db4o och JDO har väldigt lika programmeringsmodeller.
Så jag satsar mina pengar på JDO.
Kombon JDO + DataNucleus är speciellt tilltalande, eftersom DataNucleus kan använda i stort sett vad som helst för att persistera JDO-objekt; db4o, SQL-databaser, XML-filer, Excel-filer och så vidare.
Detta betyder att jag kommer att kunna enhetstesta min persistenskod mot en lokal db4o-fil, utan att behöva dra igång vare sig en separat db4o-server eller GAE:s integrationtestmiljö. Detta betyder tidsbesparingar!
Som sagt, persistensen överlåter jag med varm hand åt JDO.
Webbramverk
Här är valet betydligt svårare.
Jag är en gammal anhängare av Tapestry, som är ett komponentorienterat ramverk i samma skola som t.ex. Wicket och JSF. Jag har jobbat med Tapestry mer eller mindre kontinuerligt sedan 2003 fram till den dag som idag är.
Tyvärr fungerar inte senaste versionen av Tapestry (5.1) i GAE på grund av Tapestry använder en XML-parser som inte finns med på GAE:s white list.
Wicket lär också ha en del problem i GAE. Jag har bara hört det ryktesvägen och vet inte exakt vad de består i och om de oöverstigliga. Men eftersom jag inte kan Wicket så vill jag inte både lära mig Wicket och ta strulet med att få det att funka i GAE.
JSF har jag stött på i ett projekt, och lärt mig att avsky. Maken till krångligt ramverk får man leta efter. (JSF 2 lär vara bättre, men det har jag inte provat. Jag är inte heller lockad att prova.)
Sedan finns det c:a 100 stycken MVC-ramverk; Spring MVC, Struts, Struts 2 osv. Men har man en gång jobbat med ett komponentramverk så vill man inte tillbaka. Det känns helt enkelt inte bra.
Så mitt val är egentligen ett blindval: jag väljer ett ramverk som garanterat fungerar i GAE och som är komponentorienterat, men som jag aldrig har jobbat med: Google Web Toolkit (GWT).
Att GWT fungerar i GAE tar jag för givet, eftersom bägge är skapade av Google.
Jag har kollegor på Crisp som brukar hylla GWT, och jag litar på dem. Dessutom har jag därmed support på nära håll!
Jag tror även att GWT kommer att passa bra eftersom jag vill att Eats-o-matic skall få ett användargränssnitt mer likt en traditionell applikation än en webbapplikation. Ni vet, drag-and-drop, tab completion och liknande. Kort sagt, en Rich Internet Application…
Och eftersom jag inte är någon Javascript-guru men kan Java rätt så bra, så hoppas jag på att GWT:s javascriptabstraktion inte läcker allt för mycket, utan håller vad den lovar.
Sammanfattningsvis
Persistens: JDO
Webbramverk: GWT
Väntar med spänning på nästa sändning.
Bra inlägg eftersom jag skulle resonera likadant. 🙂 Förstås obekvämt att inte kunna välja webbramverk som man vill, Ett alternativ kanske hade varit att göra en REST-baserad lösning som lägger presentationsgränssnittet utanför, t ex i en annan webcontainer eller Swing-app. JavaFX har bra stöd för REST men det är ju stor bit att tugga i sig. Vet inte hur GAE kan stödja REST, dock.