Gerolf silently added a project in Wicket stuff that provides a Wicket JMX panel. Basic but already sweet, it once again shows you that custom components rock.
By simply doing:
add(new JmxPanel("jmx"));
you’ll have a panel that currently looks like this:
I can’t make it to JavaZone this year. I would have loved to do the talk, and visit Norway in the process, but that dreaded Wicket In Action, my day job and all the other stuff going on just doesn’t allow for that.
Fortunately, I found two people willing to stand in for me, Xavier Hanin and Gerolf Seitz. Xavier will be the one doing the talk, and he posted to the user list asking for some feedback. Good luck Xavier, and thanks! Also thanks to the JavaZone people. You’ve been great.
On a side note, I also tried to get a talk with NoFluffJustStuff in Seattle this year (which is in the weekend and next door, so that would have fitted my schedule). Unfortunately, other than ’send in your proposal’, I didn’t get any feedback from them. Quite a contrast.
For anyone using the YUI date picker from wicket-datetime: in trunk (soon beta 3) it now uses localized months and days (of week). Support is as good as the JVM allows for (the code depends on DateFormatSymbols which seems to support many locales, but not nearly all available), but if you need, you can provide your own support (override the localize method and set the appropriate properties). To test and illustrate the localized datepicker, I added a separate example in wicket-examples (/dates, package ‘org.apache.wicket.examples.dates’).
There were two locales that didn’t look quite right to me. Hindi (India) rendered question marks all over the place, and Han Chinese looked like the days were all the same. Help with would be greatly appreciated!
Btw, I renamed ‘configureWidgetProperties’ to ‘configure’ and made the old method signature final. Sorry if that broke any of you, but as long as we’re in beta I like to break rather then deprecate :).
Thanks to Gerolf Seitz for thinking with me and keeping on top of the datepicker and Al for fixing another potential render issue this week!
Yes, that’s right, you can finally start reading Wicket In Action! The first chapter can be downloaded for free. The third chapter is available when you sign up for the Manning Early Access Program (MEAP), and other chapters will follow shortly (chapter 2 and 4 hopefully next week).
It’s been quite a ride. We didn’t expect writing a book would be this hard/ take so much time. We hope it will help Wicket and it’s users. That’s ultimately the reason why we started this crazy adventure.
We are almost done with moving Wicket to be an Apache top level project. You can now find the site on http://wicket.apache.org!
Also, we are in the middle of switching our lists. Unfortunately, we can’t move the users from the sourceforge lists automatically, so please if you are subscribed to one, unsubscribe and join the Apache lists.
Moving the repository is an item that still needs to be done.
Update: the repository is moved now as well. Many thanks to Joe Schaefer/ Apache infra!
Yesterday, I committed initial Seam (2.2.0 beta) support for Wicket. For the moment, it is implemented as a test project: ‘wicket-seam-test’ in the wicket-stuff repository.
The project only has support for the @In annotation of Seam, allowing you to inject Seam components in Wicket components, and it has a simple example. Support for other Seam features might be added later if that makes sense.
The example is quity funny actually. It has this Seam component defined:
@Name("Greet")
@Scope(ScopeType.SESSION)
@AutoCreate
public class GreetService {
private int count = 0;
public GreetService() {
}
public String greet() {
return "Hello! I've greeted you " + (++count)
+ " times in this session.";
}
}
which is later used in a custom label like this:
public class GreetingsLabel extends Label {
@In
private GreetService greetService;
public GreetingsLabel(String id) {
super(id);
setModel(new AbstractReadOnlyModel() {
@Override
public Object getObject() {
return greetService.greet();
}
});
}
}
It’s just a simple example, but the interesting thing is that GreetService for the SESSION scope. Every session gets it’s own Seam managed instance. Of course, you could have accomplished the same by using a custom Wicket session, but it is nice to see an alternative way. And Seam can handle many scopes, including e.g. business process scopes. I can imagine that such things would actually be handled much nicer by Seam than if you would hand code it with just Wicket. Definitively something to further look in to!
Read more about it in the README.
UPDATE: Wicket is now supported by Seam. See this presentation for an overview.
I bought a new phone yesterday. Until then, I had still been using my Nokia 9300 with a Dutch subscription, but I finally decided it was time to get a phone in the US. And yeah, you guessed that right, it’s an iPhone. I was a little bit scared of what might be the waiting lines at first, as the media did an excellent job in hyping the hype. But after standing in line for about 50 minutes (I arrived at 5:40) I walked out with one. No problem.
It’s a very sweet toy. The screen is amazingly bright and sharp, and the touch screen works very well. And everything works very inituitive and fast. My expectations are by far exceeded - and they were high from the outset!
The key pad of my Nokia 9300 *does* work a bit faster; if you intend to use your PDA for word processing this might be a consideration for you. That said, the iPhone’s keypad works well enough for me (better than most phones I’ve tried), and I’m glad that the pad is out of the way when I don’t need it.
Here are two pictures comparing the Nokia 9300 and the iPhone.
Al added a new project for integrating Wicket with Guice. Guice (pronounced as ‘juice’) is a very elegant, focussed Dependency Injection framework. Al beat me to it; it had been on my radar for while to build such an integration project, but I didn’t want to start before I had a good idea how to re-write the phonebook example.
Jean Baptiste seems to like Guice as well, as a couple of hours after Al’s commits, I saw than he and his collegue, Vincent Demay, were already working at converting their latest pet-project, PickWick, to use Guice. Btw, JBQ and Vincent, if you ever have big plans with that project, you might want to consider a name that is different from the largest tea brand of The Netherlands :)
We are now officially graduated! Soon you can find as at http://wicket.apache.org.
I’d like to parrot Martijn, thanking the board, our mentors and ourselves for getting there. Hieperdepiep… hoera!
It’s all coming nicely together now: graduating, releasing 1.3 and entering MEAP with Wicket In Action all this summer.
We sometimes wonder how many people have installations with Wicket by now. Though there are a number of public ones we know of, like Thoof, Eventful, Vegas, Meetmoi, Zoomf, Sell@Market, Genietown, B-Side, Voicetribe, Datawink, Trackdetective, and a couple of sites with difficult names :), and we know of a couple of open source projects that use or build on Wicket, like Pax Wicket, Webical, Artifactory, JTrac, Tally-ho, Irrigator, Burgerweeshuis and Papernapkin’s pastebin, I expect most sites using Wicket to be intranet sites. That is just because it is my uneducated guess that about 80% of the webapps produced today are internal systems rather than public facing. I also expect that we only learn of a fraction of the web applications built with Wicket. I base that on the fact that I’ve been using many open source projects over the years, and rarely have signed up for their mailing lists or otherwise let people know I was using their project, and also because I have spoken to quite a few people during the last year who did not list their projects on the Wiki, but told me they were already doing their 3rd or 4rd project with Wicket.
Anyway, even if we don’t really know how well our real ‘penetration’ is, it is great to see that since the start, downloads and subscribers only have been growing, and that there is hardly any negative publicity on the framework. And that actually surprises me. There are so many choices to make in software development, that you’ll always have loads of people who think you’re doing it all wrong.
Another thing that is great is that even Wicket 1.2, our current stable release, works well for so many people. Our next release, Wicket 1.3, of which we hope to release the second beta this weekend, is a lot better than it’s predecessor in almost every aspect. I won’t go into detail here, but please, this weekend: download it and try it for yourself! Or download a snapshot from our repository of course.
Sometimes, Wicket’s dynamic component structures makes it a bit hard to figure out what on your page comes from where. Not anymore. Matej recently implemented a little but very helpful debugging aid for this in Wicket. You can turn this feature on by putting this:
@Override
protected void init() {
...
getDebugSettings().setOutputMarkupContainerClassName(true);
in your application class. Or, let it depend on a system setting you pass in your debug environment:
try {
getDebugSettings().setOutputMarkupContainerClassName(
Boolean.getBoolean("debug.markup.output"));
} catch (SecurityException e) {
// nevermind
}
so that it’s only turned on when you explicitly tell it to be turned on.
If you have this setting turned on, and you look at the sources of pages in your web browser, you’ll see fragments like this:
<!-- MARKUP FOR com.my.ViewTopicPanel$3 END -->
<span><!-- MARKUP FOR com.my.PodBorder BEGIN -->
<img src="/foo/bar.gif" />
<table >
Say, you want to locate where that crazy foo/bar image comes from, you now know that it is rendered by com.my.PodBorder, and that you can find that piece of markup in PodBorder.html or the markup associated to a parent higher up in the hierarchy.
