Wicket

Wicket is a java framework for building web applications which we're using at work, and I'm continually impressed with how easy things are to do with it. I've worked on other java projects that were just horrible though, so maybe my experience with Wicket is one that everyone else has with other frameworks - We've been down the struts approach which means holding data in eight different classes and properties files. We've been down the XML route which made the problem even worse, and we've tried out JSF and found it's really not a mature technology and you end up relying on code in obscure tag libraries.

Wicket has a HTML page with special id tags for every element that you want to be controllable from the java side - for example - td wicket:id="description" , but no JSP references or any of the crap that framework designers like to stuff in the html page making it unusable for anybody else. The HTML renders as html on its own - it's actually possible, in a real situation, to get someone to design the HTML and just plonk it into your project. I've not known this to be the case for any other framework.

For every HTML page that you want to be able to change via code, you have a Java class with the same name that sits directly alongside it. This differs from other frameworks which have the controller somewhere, the JSP page somewhere else, the tag libraries elsewhere, the form object in another area, the form validation somewhere else and the XML controlling page flow in another place. Having the page and the code next to each other makes good sense, and it's hard to see why other frameworks have deviated from this.

Also, no XML, properties or other external files. It's a single change to web.xml to get the whole caboodle to work. So effectively, when creating a new page/application, I'm dealing with two files - the html, and the java code behind that page. That's it. Well, there's still stuff to be done in the database classes to get the page to be able to fetch the data properly, but that's common to every project and I wouldn't have it any other way - the view (in this case, the wicket page) should always be separate from the data layer.

There's no real downside that I can see at this stage. The components are extensible and reasonably easy to use. The code in the java class is readable and easy to understand. The one, possible, slight niggle that I have with it is that it encourages the use of inner classes a lot. But that's not necessarily a bad thing, in fact, I'd rather have the code that executes when I click a button right by where I'm adding it to the form - the code would look something like...

add(new FeedbackPanel("feedback"); // any "error" or "info" stuff automatically appears here
Form form = new Form("monday");
Button b = new Button("submitButton"){
@Override
public void onSubmit(){
// Validation checking here
if(itsMondayMorning)
error("Go away I'm still hungover");
else
db.updateSomething();
}
};
form.add(b);
add(form);

---
Using inner classes happens all the time when doing Wicket - it does make things a bit more readable and the code flow nicely.
I'm told by someone who's worked with Swing components that the logic is similar to that, despite being in a HTML stateless environment. I don't really know having never worked with it, but it seems a doddle to get/set objects on forms.
And even when things get complicated, with fields being made invisible, buttons appearing/disappearing depending on user priveleges, validation being complex because there's a ton of fields or multiple combinations not being valid, it's still easy. It doesn't suffer from the old Visual Basic problem where to get something that looked good took 5 minutes but to get something that actually worked took a lifetime and a lot of Windows API calls.

Upsides: It's easy. It's easy to do difficult stuff and still have readable code. It's easy to bolt your database layer to. Ajax is remarkably easy to do with it. It's easily extensible (too much so?). You can write a full scale working application with just the examples from the wicket book and your code won't be any more complicated than the simple examples. The forum people are wonderful at answering questions.

Possible downsides: I think it's quite heavy on the Session object, but we've had no problems with memory usage or speed so far with a ton of users hammering it at the same time (the bottleneck is the database). Um, oh, I don't like the way it handles custom images, but there's several better ways of doing that than the default. Errrrm, and I don't like the way the URLs look by default (but again, this can be changed).

---
So, if you're struggling with your current Java framework, go and try out wicket. Even if it's not for you, it's probably worth a look.

In my job, I have to use several programming languages. Normally several a day. I've looked at asp, java, informix 4gl so far today, and it's not even lunchtime!

I'm not a programming snob, I do like some of the things "bad" languages do and detest some of the things "good" languages do.

For example - Visual Basic is generally regarded as a Bad Thing, but the fact that 'true = -1' is a brilliant coup. I'm sure C/Java programmers will read that with horror, but the fact is, if true = -1 then logical and bitwise are the same. Effectively, there's no need for having | and || to represent bit-wise and logical or statements because they are one and the same. I'm not saying that Visual Basic is good in general (it's not), but this is simply a better way of doing it.

Java's generally regarded as a Good Thing, but its error handling is one of its worst features. In theory, it provides wonderful error handling. In practice, everyone who writes library modules throws runtime exceptions instead of requiring those exceptions to be caught. This is wrong and leads to buggy code and vast error stacks that spit out Pythonesque gibberish that bear little relevance to the actual problem. I think designers don't throw normal exceptions because it breaks the "black box" model. But the black box model is decidedly broken in Java anyway, with objects merging, passing black box objects into other black boxes, and other problems.

I love the BBC, well, more specifically, I love BBC radio 4. I've just listened to the latest In our time episode which covered the "measurement problem in physics" (essentially, the problem of resolving the quantum weirdness we observe at the macro level to the newtonian mechanics which are understandable). The programme was deep, complex, thought-provoking, and suprisingly comprehensible. I do have an A-level physics qualification, but we barely covered quantum malarkey. Melvyn Bragg presented it and I was suprised how well he refereed the eminent guests (eg. Roger Penrose) despite his (probable) lack of knowledge on the subject.

That Auntie can even attempt to broadcast this in primetime to millions of listeners (Radio 4 is one of the largest radio stations in the UK) is a superb example of why you need independent broadcasters that don't depend on advertising revenues. I'm trying to think of an example of where you'd get such rich deep content without it, but I can't.

Radio 4 is pretty much unique. It's a news/spoken word radio station, it's top or close enough to being the number one listened to radio station in the UK. It doesn't do sport (unlike most other talk radio) except of course, for the incomparable test match special. It presents radio plays (eg. Douglas Adams' The Hitchiker's Guide), comedy that is either brilliant on radio permanently (I'm sorry I haven't a clue, The Now Show, etc) or can be transposed to TV too (eg. Goodness gracious me, The Frost Report which spawned Monty Python, etc), or documentaries and debate shows like the one I'm praising today. Worth the licence fee on its own!

Seduced, shaggy Samson snored.
She scissored short. Sorely shorn,
Soon shackled slave, Samson sighed.
Silently scheming,
Sightlessly seeking
Some savage, spectacular suicide.