Versions Compared

Old Version 55

changes.mady.by.user Martin Grigorov

Saved on

compared with

New Version 56

changes.mady.by.user Juegen jdonnerstag

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

We removed MarkupContainer.isTransparentResolver() in favor of the more general IComponentResolver. To make mitigate the transition easy, we provide a TransparentWebMarkupContainer. In cases where TransparentWebMarkupContainer doesn't work for you, please see TransparentWebMarkupContainer on how to achieve the same effect with your component.But please note it does not solve all use cases isTransparentResolver() did.

There are several solutions for you. Your component may implement IComponentResolver itself and resolve the child component. The TransparentWebMarkupContainer implementation may serve as an example.

Noteable difference: different Different than MarkupContainer.isTransparentResolver() where the component 's id wasn't needed in the component's path (transparent), with IComponentResolver it must be included. Imagine you used to have a transparent container such as <body wicket:id="myBody">, where you were able to access a label from the Page just by "myLabel". With the change, In 1.5. you must use "myBody:myLabel".

Another solution might be to subclass MarkupContainer.add() like discussed in WICKET-3045].

The main reason why we removed MarkupContainer.isTransparentResolver() has been the magic necessary in Wicket's core and the number of issues/questions, where we identified isTransparentResolver() as the root cause. It all boils down to that with isTransparentResolver() the markup and component hierarchies get out of sync.

IComponentResolver.resolve API has changed

...