Automatic comment and whitespace stripping for Javascript resources

Matej just committed a nice optimization for packaged Javascript references. We already compressed them, like we do with CSS references, but now, if you’re in deployment (production) mode, Wicket will also strip comments and some whitespace on the fly. Of course, the results of the compression and stripping are cached (soft references) so we’ll keep it from eating your processor.

The great thing about this optimization is that you can just develop Wicket components that use Javascript dependencies (like YUI or Dojo for instance) without having to use the production versions of those scripts (like the xx-min.js variants of YUI). Instead, you can use the source files with complete comments and formatting, without having to worry that will impact your production system.

Refactored date picker from component to behavior

Igor had a good idea, which was to implement the date picker as a behavior rather than a component. This makes it a lot nicer to use. Instead of instantiating it with the target field:

add(new DatePicker("datePicker", dateTextField);

and having to have it defined in your markup:

<div wicket:id="datePicker" />

you can now simply do:

dateTextField.add(new DatePicker());

Thanks for the idea Igor! You can find this behavior in the wicket-datetime project. Oh, and though the date picker doesn’t need the AbstractCalendar component anymore, I’ll keep it around in case people want to create components based on the YUI Calendar widget.

New project wicket-datetime (using the force)

Those of you following the developer list may already have noticed it, but this weekend I added a new core project to our repository: wicket-datetime.The motivation behind this project is the fact that dealing with the normal date API in the JDK finally drove me insane, and that for the project I’m working on we built a couple of components that depend on a much nicer date API: joda-time.Joda-time is a fantastic example of object oriented craftmanship. I find it’s API elegant and intuitive, and – very important – everything just works like you would expect it to work. That includes working with time zones, which is something I recently had to deal with.Consider this case:We have a system that logs the timestamp when entries of a certain entity were added.Now say, I’m working in Seattle, and the server is in Amsterdam. Amsterdam is nine hours ahead of Seattle. If I would be adding an entry on monday evening the 5th of february, the entry would be saved as being added on tuesday the 6th, as that is the date the server would be working in. Hence, even though it is still monday evening for me, my entry would show up in the list as being added on tuesday morning!The right thing to do here is to take the server date as the reference point, and when communicating with users (displaying and taking input), apply the time zone difference. So, in the above example, the server would store tuesday morning as the date that the entry was saved but it would show up in my browser in Seattle as monday evening.There are multiple strategies you can follow of course, like saving dates including time zone information (probably the safest route to follow), providing the client with time zone information and other variants. However, applying the time zone difference like I sketched above seemed like a generic enough solution to me to justify abstracting a few classes.The wicket-datetime project provides a Converter that takes the client’s time zone into account, and it also provides a date text field that works with this converter. Use that converter for your components, and the time zone difference will be applied for you automatically.The project also provides a new calendar/ date picker component, this time based on the Yahoo User Interface library (YUI) calendar widget. The DatePicker we had before was badly written (sorry for that, I hope I did a better job at this one) as it focussed too much on being ‘easily’ configurable. And the fact that it was based on a javascript widget that had quite a few bugs but wasn’t maintained anymore didn’t really help us feel great about the component either. There is a datepicker in the Dojo integration project, and there might be a fresh one (or two, who knows) put in the wicket-extensions project when someone (Al/ Igor/ Matej?) is up to it. But this date picker is well integrated with the other components in the project and relies of joda-time for it’s functioning (though if there is enough intrest that might be factored out).Finally, two more components that the wicket-datetime project provides at this stage are DateField and DateTimeField. The latter is a nice combination of a date text field, date picker, a field for hours and a field for minutes and a AM/PM selection.I plan to work on this component a bit too, so that it depends on the client’s locale whether a 24 hour system or a 12 hour system with AM/ PM is used.I hope people will start playing with the project soon, and I’m eagerly waiting for suggestions and patches and stuff!

Is there a Wicket – Tapestry feud?

There is none. Jonathan Locke (the guy who started Wicket) did not storm into a meeting one day, screaming “we’re going to sink Howard Lewis’ ship” and then ran off to work on his evil replacement of Tapestry.

Just about every thread on Tapestry or Wicket on The Server Side or JavaLobby degenerates in a mud slinging skirmish, and the mailing lists of both frameworks regularly have people trolling about how much better the other framework is.

I don’t know how this whole Wicket vs Tapestry thing started, but let me state this: there is no feud, and no-one of Wicket’s development team has the intention of starting one.

Tapestry’s team could be a little nicer at times and statements on their website like: ‘In some Tapestry-like frameworks, such as Faces and Wicket, the page structure is more dynamic, at the cost of storing much, much more data in the HttpSession’ are stabby.

Some of Wicket’s ‘users‘ are pretty annoying hijacking threads about Tapestry for no good reason. I quote users here, as I’m not even sure they are in the first place. Take ‘Jan de Jonge’, the guy the started the flaming in several threads. To my knowledge he is not even subscribed to one of the Wicket lists. In fact, I could not find any relationship between Wicket and him at all! But the fact that he brought up Wicket in discussion threads in quite a rude way seems to be enough evidence for other people to believe he is part of Wicket’s community.

So if you are one of the four five people in the world reading this blog: if you ever think about starting a flamefest using Wicket vs Tapestry, don’t do it for us (Wicket’s devs), as we’re not happy with it.

Tapestry is a fine framework. Wicket is based on different choices so it results in a very different programming model with different tradeoffs. Both frameworks are open source, so you can download them (or check them out from svn) and play with, look at the source, gather some statistics, whatever you want to do. The frameworks are not related other than that they are both Java web frameworks and Tapestry is an Apache project and Wicket is incubating to become one.

Enough said.