I think it should get in. -Matej
On 7/8/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
In order to fix wicket-695, I once again looked at Border. Today it is a single component and basically via different states it tries to find the relevant markup and components. This is a little bit hairy since the implementation, at least IMO, is not easy to understand and it was in the past not easy to extend or fix bugs. I did not suceed to implement wicket-695 based on that implementation. I completely rebuild Border. The new implementation uses 2 components. One, like a panel, for <span wicket:id="myBorder"> and <wicket:border> and one for <wicket:body>. The body container is created in the Borders constructor and thus is available to users right away. E.g. via border.getBodyContainer().isVisible(false) you easily solve wicket-695. Because the body is now a container, you can easily re-attach it and put a container (e.g. a Form) in between the border and the body. And you can explicitly add components to the body where auto-resolution does not work properly. To me it looks much nicer, but due to the two components it requires a little bit of extra memory. All junit tests are successful, just two (FormBorder and BorderRenderWrappedTestPage) required changes. The extended Border API has changed as well (basically it is gone), but I've not seen (or heard of) anybody using it to extend Border functionality. Extending the new Border is much more Wicket like, since it is much more based on the existing Component/MarkupContainer interfaces Though all junits test are successful, we are already at rc 1 and I wasn't sure whether I shall commit it or not. What are your thoughts? Juergen
