Page History

...

• a normal request, where the page map name parameter is provided as a part of the bookmarkable page request parameter:

  Code Block
  myapp?wicket:bookmarkablePage=myPageMap:somepackage.MyPage

• a request to a mounted URL, where the page map parameter is provided as a path encoded parameter:

  Code Block
  /myapp/mountedpage/param1/value1/wicket:pageMapName/myPageMap

What´s is the future of onAttach/onDetach methods?

Ygor Vayinberg in wicket-dev:

We are trying to consolidate the methods. We have a bunch of
internalOnAttach/internalAttach/attach/onattach methods. it's a big mess.
what this refactor does is give you one method you can override - onattach()
but forces the call to super.

Doing it like it has been done doesn't work. users assume onattach() is a
template method, they can override and not have to call super - but this
fails if you go more then one method deep!

if i create a custom component and do something in onattach(), then the user
subclasses it and they do something in onattach() and don't bother to call
super() they will break my functionality. My only choice of action is to
make onattach() final in my custom component and provide yet another
template for the user, onattach2() ? This just doesn't scale. Better to have
a simple and clear contract - onattach and ondetach always require the call
to super.

Unfortunately the only way to do that at this point and keep the same
method names is to do what i did.

OT there is a JSR for software defect annotations that includes something
like @MustCallSuper (forget what its called), that combined with an apt
builder in an ide will make these kinds of contracts very easy to enforce at
compile time. we are just not there just yet.