A Wicket Diary

Prototype.js uses direct manipulation of the style of an element instead of relying on CSS. For instance to hide and show an element they do the following (disclaimer, this is not actual prototype code, I merely interpreted it from memory):

function Element.hide(elmt) {
    elmnt.style.display = 'none';
}

function Element.show(elmt) {
    elmnt.style.display = '';
}

This works most of the time, but I think this approach is flawed in the sense that it steps over the ideas of CSS. Why don’t they have a prototype.css which does the following:

.hidden {
    display : none;
}

and in the prototype.js they could do the following:

function Element.hide(elmt) {
    elmt.addClassName('hidden');
}

function Element.show(elmt) {
    elmt.removeClassName('hidden');
}

This is cross browser compatible, and doesn’t mess with the default value of the display property. I’m not sure if setting element.style.display=”; always reverts the display property to the correct value for the element in question. But the CSS way sure feels a lot better.

I can only see the implication of deminished performance for showing and hiding elements, but I doubt you’d notice it.

Of course, this small tip is common knowledge amongst all developers that use Eclipse as their IDE, but I only recently came across it.

Eclipse doesn’t know your real name, and it doesn’t provide a way to configure it in the settings panels. The default behavior of Eclipse when inserting JavaDoc comments in your code is to use the system property user.name. This generates code like:

/**
 * @author dashorst
 */

or when working with Eclipse at home:

/**
 * @author martijn
 */

Instead I want it to generate a comment like:

/**
 * @author Martijn Dashorst
 */

Currently I have to go to the author tag and retype the generated name. Now that is not cool. And what I also don’t want to do is to change the templates that are provided by Eclipse. So, instead: I altered the eclipse.ini file, which you probably already have changed to increase the available memory and have these values:

-vmargs
-Xms128m
-Xmx512m
-Duser.name=Martijn Dashorst

The last parameter is the one that this tip concerns.

Define the user.name system property at startup of Eclipse and presto! The name of your choosing will always be correct!

As Jonathan observed yesterday, the Wicket project has entered the ranks of the SourceForge top 100 of most active projects. We are barely in the top 100 and today we moved up 9 places!

To keep our release cycle moving, I have created and uploaded a new RC release of 1.2, with several bugs fixed, and some additional localized messages as defaults. Keep them coming! Please submit your language file using the Java unicode format as used in the finnish and hungarian examples.

We now have:

• english
• french
• german
• finnish
• danish
• hungarian
• portugese (brasilian)
• chinese (taiwan)

Looking at our frappr map we can at least get 10 or so more languages implemented (japanese, swedish, norwegian, spanish, romainian, czech, polish, indian, farsi, arabic, etc)! And of course we should get someone to submit a Klingon and Swedish Chef version (does anyone know the locale keys for that)?

The list of changes between RC1 and RC2:

• Added EqualPasswordInputValidator, which doesn’t show the user input in its feedback message.
• Improved error message handling when exceptions occur during validation.
• Fixed encryption issue of password, maintaining backwards compatibility, and implementing correct URL encryption using URL safe base64 encryption.
• Added Brazilian translation of our Application.properties
• fixed FormcomponentFeedbackBorder, which didn’t display when it should
• override setModel and added setList. The override on setModel does an additional remove of the children so that - even if optimizeItemRemoval == true - the listview will be rendered with the actual contents. setList is a convenience method and is consitent with the List constructor.
• fixed window checker for case where app is configured for server root and has no web app name.

Have fun!

NOTA BENE The sourceforge upload server has let me down. It took over 2 hours to release what it currently available from the download servers, but two packages are still missing: Wicket quickstart and the Wicket Spring packages. I am unable to upload and attach the release files to the Wicket project so you will have to wait for those projects to come available. As the contents of those packages hasn’t changed other than the version number, you’ll be safe using the wicket-spring jars from 1.2-rc1 for the moment.

The
Wicket
project has released the first release candidate of the
1.2 effort.

This release is available on the SourceForge file release system for our project.
You can download the released files on the next link:

• Download Wicket-1.2-rc1

This is our first release candidate of the Wicket 1.2
version. We expect to finalize the 1.2 release very soon.
Major features of Wicket 1.2 include:

• Native, cross-platform AJAX support: use AJAX
  without having to write a single line of
  JavaScript. Wicket’s AJAX cross-platform
  capabilities
  
  have been rated ‘A’
  
• Render multiple components in one AJAX call,
  where each component can occupy any part of the
  page
• Improved markup inheritance: panels, pages,
  header contributions
• Improved and simplified internationalization
  (i18n) support, using ,
  better resource bundle lookup strategy
• Multiple form component validation, validate two
  or more fields that are related
• Improved form handling: clear form validation
  workflow that allows you to much easier defined
  required and type conversion attributes of a
  form component
• Nice URL support through URL mounting
• Markup fragments (inline panels)
• Improved performance by replacing OGNL with our
  own object graph language parser
• Response filter support, added ServerTime and
  ServerClientTime filters
• Reloading of resource bundles in development
  mode
• Improved unit test support for your Wicket
  components and pages through the WicketTester,
  create unittests that run outside the container.
• Out-of-the-box AJAX components: paging
  navigator, link with fallback, auto-updater,
  AJAX form, AJAX submit buttons, etc.
• Improved authorization and authentication
  support, giving you the power to specify
  authorization at the component level. An example
  project featuring a role based, annotation
  framework is now part of the standard
  distribution.
• Spring support for injecting your business logic
  into your web pages in a non-intrusive manner,
  while still being able to use the convenient
  Wicket idiom for creating pages (using the Java
  new
  operator).
• Improved settings system: settings are now
  partitioned into logical groupings to make them
  easier to find
• Numerous bug fixes and minor improvements

The upcoming final Wicket 1.2 release will be a
major landmark in the history of Wicket and is
highly anticipated.

We have tried to keep API changes to a minimum, but
had to change and remove some methods and classes.
Wicket 1.2 will not be a drop-in replacement for
Wicket 1.1 applications (and earlier).
Most of your application’s pages and components
should not be affected though. There is a migration guide
available on our wiki:

Migrating to Wicket 1.2

This release contains numerous fixes over the Wicket 1.2-beta3 release,
so you are encouraged to upgrade to 1.2-rc1. We consider the API to
be stable and expect following releases to be drop-in releases. We do
keep the right to break this promise in case of a nasty bug.

We hope you will download and test this release to flesh out the last
bugs. Have fun!