Abstract base class for pages. As a MarkupContainer subclass, a Page can contain a component hierarchy and markup in some markup language such as HTML. Users of the framework should not attempt to subclass Page directly. Instead they should subclass a subclass of Page that is appropriate to the markup type they are using, such as WebPage (for HTML markup).

• Construction - When a page is constructed, it is automatically added to the current PageMap in the Session. When a Page is added to the Session's PageMap, the PageMap assigns the Page an id. A PageMap is roughly equivalent to a browser window and encapsulates a set of pages accessible through that window. When a popup window is created, a new PageMap is created for the popup.
• Identity - The Session that a Page is contained in can be retrieved by calling Page.getSession(). Page identifiers start at 0 for each PageMap in the Session and increment as new pages are added to the map. The PageMap-(and Session)-unique identifier assigned to a given Page can be retrieved by calling getId(). So, the first Page added to a new user Session will always be named "0".
• LifeCycle - Subclasses of Page which are interested in lifecycle events can override onBeginRequest, onEndRequest() and onModelChanged(). The onBeginRequest() method is inherited from Component. A call to onBeginRequest() is made for every Component on a Page before page rendering begins. At the end of a request (when rendering has completed) to a Page, the onEndRequest() method is called for every Component on the Page.
• Nested Component Hierarchy - The Page class is a subclass of MarkupContainer. All MarkupContainers can have "associated markup", which resides alongside the Java code by default. All MarkupContainers are also Component containers. Through nesting, of containers, a Page can contain any arbitrary tree of Components. For more details on MarkupContainers, see MarkupContainer .
• 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.
• Models - Pages, like other Components, can have models (see IModel ). A Page can be assigned a model by passing one to the Page's constructor, by overriding initModel() or with an explicit invocation of setModel(). If the model is a CompoundPropertyModel , Components on the Page can use the Page's model implicitly via container inheritance. If a Component is not assigned a model, the initModel() override in Component will cause that Component to use the nearest CompoundModel in the parent chain, in this case, the Page's model. For basic CompoundModels, the name of the Component determines which property of the implicit page model the component is bound to. If more control is desired over the binding of Components to the page model (for example, if you want to specify some property expression other than the component's name for retrieving the model object), BoundCompoundPropertyModel can be used.
• Back Button - Pages can support the back button by enabling versioning with a call to setVersioned(boolean). If a Page is versioned and changes occur to it which need to be tracked, a verison manager will be installed using the overridable factory method newVersionManager(). The default version manager returned by the base implementation of this method is an instance of UndoPageVersionManager, which manages versions of a page by keeping change records that can be reversed at a later time.
• Security - Pages can be secured by overriding checkAccess(). If checkAccess() returns ACCESS_ALLOWED (true), then onRender() will render the page. If it returns false (ACCESS_DENIED), then onRender() will not render the page. Besides returning true or false, an implementation of checkAccess() may also choose to send the user to another page with Component.setResponsePage() or Component.redirectToInterceptPage(). This can be used to allow a user to authenticate themselves if they were denied access.