Wicket on Google App Engine

Like many others I am using Wicket on Google App Engine re-writing one of my pet projects. Google App Engine does not allow for user applications to start new threads so in order to get Wicket working, you need to disable the ModificiationWatcher by setting the resource poll frequency to NULL. This has a huge disadvantage when you're in development mode, because you'd have to restart the servlet engine each and every time you make a change in one of your HTML or other resource files.
Well - I dug into the Wicket internals and found out the ModificationWatcher was NOT meant to be plugable.. Yikes!.. Well I tried different approaches but found one that worked like a charm and it was dead simple:

Create the "org.apache.wicket.util.watch" package in your project, add a Class called ModificationWatcher and make it a copy of the ModificationWatcher from the original Wicket sources. Remove all threading but keep the base logic in the "start(Duration pollFrequency)" method.

Now override "newWebRequest" in your WebApplication class like this:

@Override
protected WebRequest newWebRequest(HttpServletRequest servletRequest) {
getResourceSettings().getResourceWatcher(true).start(getResourceSettings().getResourcePollFrequency());
return super.newWebRequest(servletRequest);
}

and vupti you've got reload of resource files again, even on Google App Engine. Remember this is only for development, but I cant see any other ways of doing it.

And to the wicket developers - please make the ModificationWathcer extendable someway.

Det har taget sin tid

... men jeg er kommet dertil hvor jeg næsten (også kun næsten) altid laver test-cases til mine klasser. Jeg laver dog meget sjældent test-first - jeg syntes ikke ens test-case skal være udslagsgiven for hvorledes jeg beslutter at implementere noget - jeg kan godt lide at have frihed til at udforske forskellige muligheder, og jeg vil derfor ofte skulle lave om i mine tests hvilket jeg syntes er unødvendigt.
Det at implementere noget, lave en test og se at testen bliver "grøn" (jeg bruger JUnit fra Eclipse) er en stor fornøjelse.
Jeg har ofte en test-case som f.eks. tester alle metoder i en klasse, og en integrationstest, der tester klassen sammenhænge med andre i kontekst så vidt det er muligt.
Det næste jeg mangler er bare en "Continous Integration Test" server, hvor alle mine hyggeprojekter bliver bygget på.. "Mjaeh - måske senere :-)"

Hygge

Så har I mig tilbage ...

... som Kurt Thorsen sagde.

Jeg er så småt begyndt at lege med Wicket igen. Efter at have arbejdet med Tapestry for mange år siden, må jeg sige at jeg har fået en forkærlighed for komponentbaserede web frameworks.

Jeg legede med JSF for et stykke tid siden, men jeg må sige at JSF på ingen måde føles så "rigtigt" som Wicket og Tapestry - dermed ikke sagt af JSF ikke har sine lyse punkter, f.eks. kan jeg godt lide tanken om "Render Kits" og det at man (måske mest i teorien) kan skifte præsentationen af JSF komponenterne ud, uden at skulle lave nogle eller mange kode-ændringer, men alligevel føltes JSF bare for "tungt". Det er faktisk svært at sætte ord på nøjagtigt hvorfor men igen, det at skrive sit eget komponent til JSF er bare væsentligt mere besværligt end at gøre det samme til Wicket (og Tapestry).

Det der gør komponentbaseret web frameworks så interessante er netop det med at det er nemt at genbruge disse "komponenter". Med ren JSP eller andet template baseret præsentationslag, oplever man ofte at man implementerer det samme igen og igen - og så er der lige det med at hvis denne logik (om det så er i en JSP include, eller implementeret som JSP Tag), skal bruge noget data fra backenden, ja så skal den "Action" (for at bruge et Struts udtryk) som forwarder til præsentationssiden, vide dette på forhånd og sørge for at aggregere alt data, som alle Tags, ell. includes skal anvende, binde det i formen eller de rigtige request attributter, og SÅ give téten videre til siden. Med komponenter i en komponentbaseret verden, sørger de selv for evt. at hente data - man kan sige at man "uddelegerer" opgaven og komponenterne er selvstændige.

Der er rigtigt mange årsager til at jeg går efter Wicket, men hvis man bli'r en smule varm om inderlårene når man tænker på Unit Tests, så bliver bekendtskabet med Wicket måske mere spændende end man havde håbet på - så knib nu benene sammen :-) :

public class MyPageComponentsTest extends TestCase {

 private WicketTester tester;

 public void setUp() {
   tester = new WicketTester();
 }

 public void testMyPageComponents() {
   WicketTester tester = new WicketTester();
   tester.startPage(MyPage.class);

   // assert rendered field components
   tester.assertComponent("myForm:firstName", TextField.class);
   tester.assertComponent("myForm:lastName", TextField.class);

   // assert rendered label components
   tester.assertLabel("myForm:firstNameLabel", "First Name");
   tester.assertLabel("myForm:lastNameLabel", "Last Name");
 }

 public void testOnClickAction() {
   tester.startPage(MyPage.class);

   // click link and render
   tester.clickLink("nextPage");

   tester.assertRenderedPage(NextPage.class);
   tester.assertLabel("nextPageMessage", "Hello!");
 }

Ja - det er da nogle tests som IKKE er nemme at lave for JSP sider :-)