rendering

pros

• more component driven then markup driven
• when implementing custom rendering no need to mess with the mysterious markup stream
• allows independent rendering of body only ( good for ajax )

cons

link components through constructor not via add(Component parent)

pros

• super-early failure on mismatches between component hierarchy/markup hierarchy (in Component constructor instead of at render time)
• access to component's markup in component's constructor. This means getPage(), getPath() work in the constructor, you can also read tag attributes (table wicket:id="dataview: wicket:rowsPerPage="10") and will be able to modify them (eliminating attr modifiers for simple modifications)

cons

• breaks all previous versions

converters

We should really make a converter that does 2 ways:
convertToString(Object, Locale)
convertToObject(String, Class, Locale)

then we can kill the ITypeConverter interface
the current Converter object can then be CompoundConverter which just maps the convert call to the right converter.

then for example the current DateConverter and DateToStringConverter should be merged into one IConverter class

pros

• It will be then much easier to make youre own converter. You only have one type of class (IConverter)
• You can alter the CompoundConverter easier. Because you register just one converter for both kind of inputs.
• Also if you override FormComponent.getConverter() you can really just return the Type Converter if you know that that formcomponent just has one know type to handle.