Wicket Components - have to add() every time?

Question

I am attempting to build a simple application using wicket and have been impressed so far. I have been taking advantage of the Component class to determine behavior of elements on the page based on user input or the model. I see the component model similarities with JSF, but find the wicket lifecycle easier to manage.

What i haven't been able to understand is having to add every component to the tree for every wicket:id mentioned on a page, especially for ones without any children. it seems heavy handed to have to build up the tree in java code when the tree has already been somewhat defined within the markup. what am i missing?

edit

I should probably give an example. I have a label for an input box that in some cases i want to be able to modify. 95% of the time the text and attributes i have for the label in markup will be fine.

Answer 1

Offcurse you should add them.One of the most powerful facilities of wicket is that allow you to make a reusable components espacially html components.

There are a million ways to build a house, but most people wouldn’t consider building toilets, bathtubs, and glass windows from scratch. Why build a toilet yourself when you can buy one for less money than it would cost you to construct it, and when it’s unlikely you’ll produce a better one than you can get in a shop? In the same fashion, most software engineers try to reuse software modules. “Make or buy” decisions encompass more than whether a module is available; generally, reusing software modules is cheaper and leads to more robust systems. Reusing software also means you don’t have to code the same functionality over and over again.(wicket in action:manning)

So to have a reusable wicket pages, wicket just needs a html page to show it's components hierarchy or their positions. The types and model of these components left to programmer.

Answer 2

I have a label for an input box that in some cases i want to be able to modify. 95% of the time the text and attributes i have for the label in markup will be fine.

You could try to wrap the content of the label in a Model, enclose that label in a container and repaint the container (target.add(container);).

Answer 3

Short answer: Yes, you have to add them.

Long answer: You can create custom code to do this, but I doubt it's worth the effort.

With JSF, you use a non-html tag, which has one component type associated to it - for example, h:inputText correspond to the class HtmlInputText -, so it knows what class to instantiate.

With Wicket, the HTML file contains only (with a few exceptions) HTML tags, and you have to instantiate a concrete component for each wicket:id-marked tag you add to the markup, because it can't know for sure if <span wicket:id='xyz'> means a Label, a FeedbackPanel, a WebMarkupContainer, or some custom component.

With JSF you do in the markup what, with Wicket, you do in Java code, that is, to build the component tree, bind components to properties, and handle events. It keeps everything in one file (you don't have to create a class for every template file), which has many, many cons (some may think it has some pros, I digress).

You page is never just a simple form that does nothing. You want to convert and validate the input, you want to process the submit, you want to update components using Ajax. With JSF, you do all that in the (non-compilable, type-unsafe, poorly tooled, non-refactorable) template, making it bloated with expressions, configuration tags, and - gawd forbid - business logic.

If Wicket had support for this (and, for the matter, it has the flexibility needed for you to build this add-on yourself), you would have to add lots of extra annotations (special, non-standard tags and attributes) to the markup, to declare what class to instantiate, what model to update, what validations to execute, etc., compromising two of the beauties of the framework, the clean HTML template, and the clear separation between visuals and logic.

One framework that tries to do more in the template, while remaining less bloated than JSF (which isn't that hard anyway) is Apache Tapestry. But as can be seen in its tutorial, you still end up having to use non-standard tags and following arbitrary conventions to bind the template to the code (you may like it, but if this is the case you have baaad taste, sorry :P).