Tag Archives: Tapestry

Äventyr i molnet – del 3

Posted on by

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

Ouch, Howard Lewis Ship dumpar Maven

Posted on by

Skaparen av Tapestry, Howard Lewis Ship, dumpar nu Maven, efter att ha använt det väldigt mycket. Citat från hans blog:

The Maven team is criminal…

The Maven project site is an embarrassment. The tool supposedly designed for "project comprehension" is itself incomprehensible, due to its scale, the chaos of its documentation, and the extreme lack of engineering discipline evidenced by its maintainers.

Get out while you still can.

Inom Crisp har vi två fraktioner, en som gillar Maven och använder det mycket, och en annan grupp som är skeptisk. Jag hör till den senare gruppen, efter att ha sett ett projekt nästan snubbla på Maven. Dessutom är jag är en stor fan av Hani Suleiman, och han avskyr Maven.

Den senaste tiden har jag sett många projekt gå över till Maven, bland annat är det mycket använt i Scala, och just nu sitter jag på Jfokus och lyssnar på ett föredrag om Apache ServiceMix, och de använder också Maven. Men Ships inlägg gör att jag inte kommer att rekommendera Maven om inte projektet där det ska användas är rätt enkelt i sin struktur.

Är Wicket nästa stora webbramverk för Java?

Posted on by

Genom åren har jag skrivit webb applikationer med Servlets, JSP och nu senast Tapestry, som jag länge sett som det bästa av dem alla, mest för att det är komponentbaserat och för att template filerna är plain vanilla HTML. Min senaste brottningsmatch med Tapestry var tyvärr inte helt angenäm. Ofta var det enkelt att använda, men ibland blev lösningarna oroväckande bakvända. Dokumentationen för Tapestry är inte heller helt tillfredsställande, och jag förstår fortfarande inte page rewinding!

Sedan Wicket kom för något drygt år sedan har jag varit mycket sugen på att prova det. För några veckor sedan såg jag ett Java jobb här i Stockholm där de sökte personer kunniga i Wicket!

Hur som helst så har Peter Thomas skrivit en lång utvärdering av Wicket gentemot Spring MVC, och från min synvinkel är den ganska rättvis. Jag har bara sett Spring MVC på avstånd, men inte blivit imponerad.