This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Stateless pages
Skip to end of metadata
Go to start of metadata
Table of contents

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.

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

Stateless pages in 1.3 (backported from 2.0)

 
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 by overriding Component#getStatelessHint() or IBehavior#getStatelessHint() method. By default most components and behaviors (except for ajax behaviors) have stateless hint returning true.

Component is considered stateless if it and all its behaviors hint that they are stateless. As long as all components on a page are stateless and the page is bookmarkable (see Bookmarkable pages and links), the page is regarded stateless. You can set stateless hint for a page using Page#setStatelessHint() method. It is useful when you want to be sure that page is stateless. If this hint is set to true but the page contains some stateful components you will be warned. But unlike a component if you set this hint to false the page can still be stateless if all components on it are stateless.

The most common and not stateless components are Link and Form. To use links and forms in a stateless way there are convenience classes StatelessLink and StatelessForm. Notice that every time a stateless page is requested wicket (at least 1.3) creates new instance of that page, so in event handling code of form or link you should assume that page's member variables don't have the same values they had in the "previous" instance of that page.

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.

public class MyPage extends WebPage {
    private int i;

    public MyPage(PageParameters parameters) {
        add(new StatelessLink("link") {
            public void onClick() {
                System.out.println(i++); // will always print 0
                // you can use PageParameters
                setResponsePage(AnotherPage.class);
            }
        });
    }
}

Since the StatelessForm is almost like a normal form, the onSubmit will be pretty much the same as for normal form. Except when you rely on state outside the form components itself, such as 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.

public class MyPage2 extends WebPage {
    private final Map<String, String> map = new HashMap<String, String>();

    public MyPage2() {
        map.put("text", null);
        map.put("anotherText", null);
        final StatelessForm form = new StatelessForm("form", new CompoundPropertyModel(map)) {
            protected void onSubmit() {
                // map here contains submitted data
                System.out.println(map.get("text"));
                System.out.println(map.get("anotherText"));
                map.put("anotherText", "this will never be printed");
            }
        };
        form.add(new TextField("text"));
        add(form);
    }
}

TODO expand, give some examples. is it ok?

See also explanation on the list

  • No labels