Stateless pages in 1.2.x

Stateless pages were introduced in a basic form in 1.2 for the first time. Stateless here means the page isn't even stored in the session. A page is marked stateless if it doesn't have any call backs to itself (Links, Forms, etc). So for 1.2, if you implement all your functionality using bookmarkable pages and passing 'state' using RequestParameters objects, you'll have hardly any session usage (note hardly, as for 1.2 a session object is still created for every client).

Also to express it a bit more: Bookmarkable Urls, i do say here on purpose Urls and not Pages!, don't say anything about the statefull or stateless nature of a page! That is only a entry point (url) to the page that is stable even without a session. Nothing more, if that is hit and the page is created then the page itself can be statefull because it can have statefull links or forms or behaviours (ajax) inside it.

Careful use of setResponsePage

Be careful to use Component.setResponsePage(Class) or Component.setResponsePage(Class, PageParameters) in favour of Component.setResponsePage(Page). The latter can be stateful if you redirect to that page, so you have to call setRedirect(false) also, otherwise the page is stateful because the page has to be there after the redirect so that Wicket can render it.

Careful use of page links

Be careful to use BookmarkablePageLink in favour of PageLink. The latter is stateful by design.

Stateless pages in 2.0 (and backported to 1.3)

Since 1.3/ 2.0, Wicket supports deferred session creation. So as long as you use stateless pages, there won't be any session created at all.

Stateless support was extended in 2.0 (and 1.3) to allow much more control in whether/ when a (bookmarkable) page is flagged stateless. You can now mark components and behaviors (e.g. ajax) with callbacks as being stateless. As long as all components and behaviors on a page are stateless, the page is regarded stateless. Convenience classes that support this are StatelessLink and StatelessForm.

Where the StatelessForm is almost like an normal form, the onSubmit would be pretty much the same as a normal form. Except when you rely on state outside the form components itself, so page state
or state that isn't pushed by the post data. So if your onSubmit code just depends on the form state that got pushed by the submit of the browser, what is normally the case, then there is no change at all.
A StatelessLink can currently only be something like a navigation link. Or if you generate the url with some extra info you can get that from the RequestParameters and use that.

TODO expand, give some examples.

See also explanation on the list