Bookmarkable vs non-bookmarkable pages
Pages can be constructed with any constructor when they are being used in a Wicket session, but if you wish to link to a Page using a URL that is "bookmarkable" (which implies that the URL will not have any session information encoded in it, and that you can call this page directly without having a session first directly from your browser), you need to implement your Page with a no-arg constructor or with a constructor that accepts a PageParameters argument (which wraps any query string parameters for a request). In case the page has both constructors, the constructor with PageParameters will be used.
If you have a Page with a default constructor and not a PageParameter constructor then it will default to one without any warning or error. Because wicket doesn't check if there are really request parameters for it and wicket can't know if they are really meant for this page or not.
Non-bookmarkable pages have default constructors and constructors with the
PageParameters argument hidden (protected/private), or none at all. It could have any other constructor, like
MyPage(FooClass bar) etc. The net effect of your page being non-bookmarkable is that there is no way a user can directly access your page. So, by making a page non-bookmarkable, you make it a 'safe' page.
A recommended approach is that bookmarkable pages do nothing in their default behaviour (construction time) that can harm you (like deleting records etc), and that everything you want to hide, should be either put in protected pages, or in handlers such as links and forms on the pages. Note that those handlers are protected too, as they can never be called directly without having created the page instance first.
Linking to pages can be done in multiple ways:
First one is by just using the Link class directly:
This way you instantiate the page and set it as response page when the link is clicked on.
You can also use
PageLink class, in three ways:
This constructor just makes a new instance of that Page when the link is clicked by its default constructor, which it must have.
Second is with a Page directly in the constructor so that you have to make your place when you create the link:
You could also use the constructor with the IPageLink interface so that you can lazy initialize the page:
And a IPageLink implementation could be something like this:
So you control the page creation and which constructor is called.
linksTo of a
Link just returns false and for a
PageLink it just checks for the page class. But if your page has state then you should implement that method yourself and check if the state matches:
For a page that has state the defaults
linksTo(Page page) of a
PageLink doesn't fit you should override this method and use an implementation that checks the state of that page:
Lastly, if your page has a default constructor or if you must push state to it that can be mapped into strings, then you could also use the
PageParameters. This results in pushing a bit more state to the client, and the URL's looks a bit different.