You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by ad...@apache.org on 2013/12/19 22:43:38 UTC
svn commit: r1552439 [2/2] - in /wicket/common/site/trunk/_site/guide: gapi/
gapi/DefaultPackage/ gapi/spring/ guide/ guide/pages/
guide/src/docs/guide/chapter10/ guide/src/docs/guide/chapter19/
guide/src/docs/guide/chapter4/ guide/src/docs/guide/chapt...
Modified: wicket/common/site/trunk/_site/guide/guide/pages/chapter8_4.html
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/pages/chapter8_4.html?rev=1552439&r1=1552438&r2=1552439&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/pages/chapter8_4.html (original)
+++ wicket/common/site/trunk/_site/guide/guide/pages/chapter8_4.html Thu Dec 19 21:43:37 2013
@@ -157,7 +157,7 @@ function addJsClass() {
<h2 id="chapter8_4">9.4 Session Class</h2>
-<p class="paragraph"/>In Wicket we use class <code>org.apache.wicket.Session</code> to handle session-relative informations such as client informations, session attributes, session-level cache (seen in paragraph 6.2.4), etc...<p class="paragraph"/>In addition, we know from paragraph 6.1 that Wicket creates a user session to store versions of stateful pages. Similarly to what happens with RequestCycle, the new Session's instances are generated by the <code>Application</code> class with the <code>newSession(Request request, Response response)</code> method. This method is not declared as final, hence it can be overridden if we need to use a custom implementation of the Session class.<p class="paragraph"/>By default if our custom application class is a subclass of WebApplication, method newSession will return an instance of class <code>org.apache.wicket.protocol.http.WebSession</code>. As we have mentioned talking about <code>RequestCycle</code>, also class Session provides a static <c
ode>get()</code> method which returns the session associated to the current thread.<p class="paragraph"/><h3>Session and listeners</h3><p class="paragraph"/>Similar to the <code>RequestCycle</code>, class <code>org.apache.wicket.Session</code> also offers support for listener entities. With Session these entities must implement the callback interface <code>org.apache.wicket.ISessionListener</code> which exposes only the <code>onCreated(Session session)</code> method. As you might guess from its name, this method is called when a new session is created. Session listeners must be added to our application using a typed collection, just like we have done before with request cycle listeners:<p class="paragraph"/><div class="code"><pre>@Override
+<p class="paragraph"/>In Wicket we use class <code>org.apache.wicket.Session</code> to handle session-relative informations such as client informations, session attributes, session-level cache (seen in paragraph 8.2), etc...<p class="paragraph"/>In addition, we know from paragraph 8.1 that Wicket creates a user session to store versions of stateful pages. Similarly to what happens with RequestCycle, the new Session's instances are generated by the <code>Application</code> class with the <code>newSession(Request request, Response response)</code> method. This method is not declared as final, hence it can be overridden if we need to use a custom implementation of the Session class.<p class="paragraph"/>By default if our custom application class is a subclass of WebApplication, method newSession will return an instance of class <code>org.apache.wicket.protocol.http.WebSession</code>. As we have mentioned talking about <code>RequestCycle</code>, also class Session provides a static <cod
e>get()</code> method which returns the session associated to the current thread.<p class="paragraph"/><h3>Session and listeners</h3><p class="paragraph"/>Similar to the <code>RequestCycle</code>, class <code>org.apache.wicket.Session</code> also offers support for listener entities. With Session these entities must implement the callback interface <code>org.apache.wicket.ISessionListener</code> which exposes only the <code>onCreated(Session session)</code> method. As you might guess from its name, this method is called when a new session is created. Session listeners must be added to our application using a typed collection, just like we have done before with request cycle listeners:<p class="paragraph"/><div class="code"><pre>@Override
<span class="java-keyword">public</span> void init(){<p class="paragraph"/> <span class="java-keyword">super</span>.init();<p class="paragraph"/> //listener initialization…
ISessionListener myListener;
//add a custom session listener
Modified: wicket/common/site/trunk/_site/guide/guide/pages/chapter8_5.html
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/pages/chapter8_5.html?rev=1552439&r1=1552438&r2=1552439&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/pages/chapter8_5.html (original)
+++ wicket/common/site/trunk/_site/guide/guide/pages/chapter8_5.html Thu Dec 19 21:43:37 2013
@@ -157,7 +157,7 @@ function addJsClass() {
<h2 id="chapter8_5">9.5 Summary</h2>
-<p class="paragraph"/>In this chapter we had a look at how Wicket internally handles a web request. Even if most of the time we won't need to customize this internal process, knowing how it works is essential to use the framework at 100%.<p class="paragraph"/>Entities like Application and Session will come in handy again when we will tackle the topic of security in chapter 18.
+<p class="paragraph"/>In this chapter we had a look at how Wicket internally handles a web request. Even if most of the time we won't need to customize this internal process, knowing how it works is essential to use the framework at 100%.<p class="paragraph"/>Entities like Application and Session will come in handy again when we will tackle the topic of security in chapter 20.
<div style="clear:both;margin-top:15px;"></div>
Modified: wicket/common/site/trunk/_site/guide/guide/single.html
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/single.html?rev=1552439&r1=1552438&r2=1552439&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/single.html (original)
+++ wicket/common/site/trunk/_site/guide/guide/single.html Thu Dec 19 21:43:37 2013
@@ -656,7 +656,7 @@ For the sake of simplicity we can consid
<h2 id="chapter4_2">5.2 Here comes the inheritance!</h2>
The need of ensuring a consistent layout across our pages unveiled a serious limit of the HTML: the inability to apply inheritance to web pages and their markup. Wouldn't be great if we could write our layout once in a page and then inherit it in the other pages of our application?
One of the goals of Wicket is to overcome this kind of limit.<p class="paragraph"/><h3>Markup inheritance</h3><p class="paragraph"/>As we have seen in the previous chapter, Wicket pages are pure Java classes, so we can easily write a page which is a subclass of another parent page. But in Wicket inheritance is not limited to the classic object-oriented code inheritance. When a class subclasses a <code>WebPage</code> it also inherits the HTML file of to the parent class. This type of inheritance is called markup inheritance.
-To better illustrate this concept let's consider the following example where we have a page class called <code>GenericSitePage</code> with the corresponding HTML file GenericSitePage.html. Now let's create a specific page called <code>OrderCheckOutPage</code> where users can check out their orders on our our web site. This class extends <code>GenericSitePage</code> but we don't provide it with any corresponding HTML file.
+To better illustrate this concept let's consider the following example where we have a page class called <code>GenericSitePage</code> with the corresponding HTML file GenericSitePage.html. Now let's create a specific page called <code>OrderCheckOutPage</code> where users can check out their orders on our web site. This class extends <code>GenericSitePage</code> but we don't provide it with any corresponding HTML file.
In this scenario <code>OrderCheckOutPage</code> will use GenericSitePage.html as markup file:<p class="paragraph"/><img border="0" class="center" src="../img/markup-inheritance.png"></img><p class="paragraph"/>Markup inheritance comes in handy for page layout management as it helps us avoid the burden of checking that each page conforms to the site layout. However to fully take advantage of markup inheritance we must first learn how to use another important component of the framework that supports this feature: the panel.<p class="paragraph"/><blockquote class="warning">
If no markup is found (nor directly assigned to the class, neither inherited from an ancestor) a <code>MarkupNotFoundException</code> is thrown.
</blockquote><p class="paragraph"/><h3>Panel class</h3><p class="paragraph"/>Class <code>org.apache.wicket.markup.html.panel.Panel</code> is a special component which lets us reuse GUI code and HTML markup across different pages and different web applications. It shares a common ancestor class with WebPage class, which is <code>org.apache.wicket.MarkupContainer</code>:<p class="paragraph"/><img border="0" class="center" src="../img/page-panel-hierarchy.png"></img><p class="paragraph"/> <em class="italic">Illustration: Hierarchy of WebPage and Panel classes</em> <p class="paragraph"/>Subclasses of <code>MarkupContainer</code> can contain children components that can be added with method <code>add(Component...)</code> (seen in <a href="../guide/single.html#chapter3_3" class="guide">chapter 3.3</a>). <code>MarkupContainer</code> implements a full set of methods to manage children components. The basic operations we can do on them are:
@@ -955,7 +955,7 @@ add(label);</pre></div><p class="paragra
<h2 id="chapter5_9">6.9 Hiding decorating elements with the wicket:enclosure tag</h2>
Our data are rarely displayed alone without a caption or other graphic elements that make clear the meaning of their value. For example:<p class="paragraph"/><div class="code"><pre><label>Total amount: </label><span wicket:id=<span class="java-quote">"totalAmount"</span>></span></pre></div><p class="paragraph"/>Wicket comes with a nice utility tag called <code><wicket:enclosure></code> that automatically hides those decorating elements if the related data value is not visible. All we have to do is to put the involved markup inside this tag. Applying <code><wicket:enclosure></code> to the previous example we get the following markup:<p class="paragraph"/><div class="code"><pre><wicket:enclosure>
<label>Total amount: </label><span wicket:id=<span class="java-quote">"totalAmount"</span>></span>
-</wicket:enclosure></pre></div><p class="paragraph"/>Now if component <code>totalAmount</code> is not visible, its description (<code>Total amount:</code>) will be automatically hidden. If we have more then a Wicket component inside <code><wicket:enclosure></code> we can use <code>child</code> attribute to specify which component will control the overall visibility:<p class="paragraph"/><div class="code"><pre><wicket:enclosure child=<span class="java-quote">"totalAmount"</span>>
+</wicket:enclosure></pre></div><p class="paragraph"/>Now if component <code>totalAmount</code> is not visible, its description (<code>Total amount:</code>) will be automatically hidden. If we have more than a Wicket component inside <code><wicket:enclosure></code> we can use <code>child</code> attribute to specify which component will control the overall visibility:<p class="paragraph"/><div class="code"><pre><wicket:enclosure child=<span class="java-quote">"totalAmount"</span>>
<label>Total amount: </label><span wicket:id=<span class="java-quote">"totalAmount"</span>></span><br/>
<label>Expected delivery date: </label><span wicket:id=<span class="java-quote">"delivDate"</span>></span>
</wicket:enclosure></pre></div><p class="paragraph"/><code>child</code> attribute supports also nested components with a colon-separated path:<p class="paragraph"/><div class="code"><pre><wicket:enclosure child=<span class="java-quote">"totalAmountContainer:totalAmount"</span>>
@@ -1109,9 +1109,9 @@ This chapter explains how Wicket manages
<h2 id="chapter7_1">8.1 Stateful pages vs stateless</h2>
-<p class="paragraph"/>Wicket pages can be divided into two categories: stateful and stateless pages. Stateful pages are those which rely on user session to store they internal state and to keep track of user interaction.
+<p class="paragraph"/>Wicket pages can be divided into two categories: stateful and stateless pages. Stateful pages are those which rely on user session to store their internal state and to keep track of user interaction.
On the contrary stateless pages are those which don't change their internal state during their lifecycle and they don't need to occupy space into user session.<p class="paragraph"/>From Wicket's point of view the biggest difference between these two types of page is that stateful pages are versioned, meaning that they will be saved into user session every time their internal state has changed. Wicket automatically assigns a session to the user the first time a stateful page is requested. Page versions are stored into user session using Java Serialization mechanism.
-Stateless pages are never versioned and that's why they don't require a valid user session. If we want to know whether a page is stateless or not, we can call the isPageStateless() method of class Page.<p class="paragraph"/>In order to build a stateless page we must comply with some rules to ensure that the page won't need to use user session. These rules are illustrated in paragraph 6.3 but before talking about stateless pages we must first understand how stateful pages are handled and why they are versioned.
+Stateless pages are never versioned and that's why they don't require a valid user session. If we want to know whether a page is stateless or not, we can call the isPageStateless() method of class Page.<p class="paragraph"/>In order to build a stateless page we must comply with some rules to ensure that the page won't need to use user session. These rules are illustrated in paragraph 8.3 but before talking about stateless pages we must first understand how stateful pages are handled and why they are versioned.
<h2 id="chapter7_2">8.2 Stateful pages</h2>
@@ -1133,7 +1133,7 @@ Stateless pages are never versioned and
}</pre></div><p class="paragraph"/>Now if we run the new example (project LifeCycleStagesRevisited) and we click on the âReloadâ button, a new page version is created and the page id is increased by one:<p class="paragraph"/><img border="0" class="center" src="../img/reload-page.png"></img><p class="paragraph"/>If we press the back button the page version previously rendered (and serialized) will be retrieved (i.e. deserialized) and it will be used again to respond to our request (and page id is decremented):<p class="paragraph"/><img border="0" class="center" src="../img/browser-back.png"></img><p class="paragraph"/><blockquote class="note">
For more details about page storing you can visit the wiki page at https://cwiki.apache.org/confluence/display/WICKET/Page+Storage .
On this page you can find which classes are involved into page storing mechanism and how they work together.
-</blockquote><p class="paragraph"/>As we have stated at the beginning of this chapter, page versions are stored using Java serialization, therefore every object referenced inside a page must be serializable1. In paragraph 9.6 we will see how to overcome this limit and work with non-serializable objects in our components using detachable Wicket models.<p class="paragraph"/><h3>Using a specific page version with PageReference</h3><p class="paragraph"/>To retrieve a specific page version in our code we can use class <code>org.apache.wicket.PageReference</code> by providing its constructor with the corresponding page id:<p class="paragraph"/><div class="code"><pre>//load page version with page id = 3
+</blockquote><p class="paragraph"/>As we have stated at the beginning of this chapter, page versions are stored using Java serialization, therefore every object referenced inside a page must be serializable. In paragraph 9.6 we will see how to overcome this limit and work with non-serializable objects in our components using detachable Wicket models.<p class="paragraph"/><h3>Using a specific page version with PageReference</h3><p class="paragraph"/>To retrieve a specific page version in our code we can use class <code>org.apache.wicket.PageReference</code> by providing its constructor with the corresponding page id:<p class="paragraph"/><div class="code"><pre>//load page version with page id = 3
PageReference pageReference = <span class="java-keyword">new</span> PageReference(3);
//load the related page instance
Page page = pageReference.getPage();</pre></div><p class="paragraph"/>To get the related page instance we must use method getPage.<p class="paragraph"/><h3>Turning off page versioning</h3><p class="paragraph"/>If for any reason we need to switch off versioning for a given page, we can call its method setVersioned(false).<p class="paragraph"/><h3>Pluggable serialization</h3><p class="paragraph"/>Starting from version 1.5 it is possible to choose which implementation of Java serialization will be used by Wicket to store page versions. Wicket serializes pages using an implementation of interface <code>org.apache.wicket.serialize.ISerializer</code>. The default implementation is <code>org.apache.wicket.serialize.java.JavaSerializer</code> and it uses the standard Java serialization mechanism based on classes ObjectOutputStream and ObjectInputStream. However on Internet we can find other interesting serialization libraries like Kryo1 which performs faster then the standard implementation
.The serializer in use can be customized with the setSerializer(ISerializer) method defined by setting interface <code>org.apache.wicket.settings.IFrameworkSettings</code>.<p class="paragraph"/>We can access this interface inside the method init of the class Application using the getFrameworkSettings() method :<p class="paragraph"/><div class="code"><pre>@Override
@@ -1190,7 +1190,7 @@ Page '<page class>' is not state
<h2 id="chapter7_4">8.4 Summary</h2>
-<p class="paragraph"/>In this chapter we have seen how page instances are managed by Wicket. We have learnt that pages can be divided into two families: stateless and stateful pages. Knowing the difference between the two types of pages is important to build the right page for a given task.<p class="paragraph"/>However, to complete the discussion about stateless pages we still have to deal with two topics we have just outlined in this chapter: class PageParameters and bookmarkable pages. The first part of chapter 8 will cover these missing topics.
+<p class="paragraph"/>In this chapter we have seen how page instances are managed by Wicket. We have learnt that pages can be divided into two families: stateless and stateful pages. Knowing the difference between the two types of pages is important to build the right page for a given task.<p class="paragraph"/>However, to complete the discussion about stateless pages we still have to deal with two topics we have just outlined in this chapter: class PageParameters and bookmarkable pages. The first part of chapter 10 will cover these missing topics.
<h1 id="chapter8">9 Under the hood of the request processing</h1>
@@ -1213,7 +1213,7 @@ The implementation of the get method tak
<span class="java-keyword">return</span> RequestCycle.get();
}</pre></div><p class="paragraph"/><h3>RequestCycle and request processing</h3><p class="paragraph"/><blockquote class="note">
This paragraph will provide just the basic informations about what happens behind the scenes of request processing. When you work with Wicket it's unlikely to have a need for customizing this process, so we won't cover this topic in detail.
-</blockquote><p class="paragraph"/>In order to process a request, <code>RequestCycle</code> delegates the task to another entity which implements interface <code>org.apache.wicket.request.IRequestHandler</code>. There are different implementations of this interface, each suited for a particular type of requested resource (a page to render, an AJAX request, an URL to an external page, etc.).<p class="paragraph"/>To resolve the right handler for a given HTTP request, the <code>RequestCycle</code> uses a set of objects implementing the <code>org.apache.wicket.request.IRequestMapper</code> interface. The mapping interface defines the <code>getCompatibilityScore(Request request)</code> method which returns a score indicating how compatible the request mapper is for the current request. <code>RequestCycle</code> will choose the mapper with the highest score and it will call its <code>mapRequest(Request request)</code> method to get the proper handler for the given request. Once <code>Requ
estCycle</code> has resolved a request handler, it invokes its method <code>respond(IRequestCycle requestCycle)</code> to start request processing.<p class="paragraph"/>The following sequence diagram recaps how a request handler is resolved by the <code>RequestCycle</code>:<p class="paragraph"/><img border="0" class="center" src="../img/request-cycle-handler.png"></img><p class="paragraph"/>Developers can create additional implementations of IRequestMapper and add them to their application via the mount(IRequestMapper mapper) method of the WebApplication class. In paragraph 8.6 we will see how Wicket uses this method to add built-in mappers for mounted pages.<p class="paragraph"/><h3>Generating URL with the urlFor and mapUrlFor methods</h3><p class="paragraph"/>The RequestCycle is also responsible for generating the URL value (as CharSequence) for the following entities:
+</blockquote><p class="paragraph"/>In order to process a request, <code>RequestCycle</code> delegates the task to another entity which implements interface <code>org.apache.wicket.request.IRequestHandler</code>. There are different implementations of this interface, each suited for a particular type of requested resource (a page to render, an AJAX request, an URL to an external page, etc.).<p class="paragraph"/>To resolve the right handler for a given HTTP request, the <code>RequestCycle</code> uses a set of objects implementing the <code>org.apache.wicket.request.IRequestMapper</code> interface. The mapping interface defines the <code>getCompatibilityScore(Request request)</code> method which returns a score indicating how compatible the request mapper is for the current request. <code>RequestCycle</code> will choose the mapper with the highest score and it will call its <code>mapRequest(Request request)</code> method to get the proper handler for the given request. Once <code>Requ
estCycle</code> has resolved a request handler, it invokes its method <code>respond(IRequestCycle requestCycle)</code> to start request processing.<p class="paragraph"/>The following sequence diagram recaps how a request handler is resolved by the <code>RequestCycle</code>:<p class="paragraph"/><img border="0" class="center" src="../img/request-cycle-handler.png"></img><p class="paragraph"/>Developers can create additional implementations of IRequestMapper and add them to their application via the mount(IRequestMapper mapper) method of the WebApplication class. In paragraph 10.6 we will see how Wicket uses this method to add built-in mappers for mounted pages.<p class="paragraph"/><h3>Generating URL with the urlFor and mapUrlFor methods</h3><p class="paragraph"/>The RequestCycle is also responsible for generating the URL value (as CharSequence) for the following entities:
<ul class="star">
<li>a page class, via the <code>urlFor(Class<C> pageClass, PageParameters parameters)</code> method</li>
<li>an IRequestHandler via the <code>urlFor(IRequestHandler handler)</code> method</li>
@@ -1224,7 +1224,7 @@ This paragraph will provide just the bas
<ul class="star">
<li><strong class="bold">onBeginRequest():</strong> called when the RequestCycle is about to start handling the request.</li>
<li><strong class="bold">onEndRequest():</strong> called when the RequestCycle has finished to handle the request</li>
-<li><strong class="bold">onDetach():</strong> called after the request handling has completed and the RequestCycle is about to be detached from its thread. The default implementation of this method invokes detach() on the current session (the Session class will be shortly discussed in paragraph 7.4).</li>
+<li><strong class="bold">onDetach():</strong> called after the request handling has completed and the RequestCycle is about to be detached from its thread. The default implementation of this method invokes detach() on the current session (the Session class will be shortly discussed in paragraph 9.4).</li>
</ul><p class="paragraph"/>Methods onBeforeRequest and onEndRequest can be used if we need to execute custom actions before and after business code is executed, such as opening a Hibernate/JPA session and closing it when code has terminated.<p class="paragraph"/>A more flexible way to interact with the request processing is to use the listener interface <code>org.apache.wicket.request.cycle.IRequestCycleListener</code>. In addition to the three methods already seen for RequestCycle, this interface offers further hooks into request processing:
<ul class="star">
<li><strong class="bold">onBeginRequest(RequestCycle cycle):</strong> (see the description above)</li>
@@ -1244,7 +1244,7 @@ This paragraph will provide just the bas
<h2 id="chapter8_4">9.4 Session Class</h2>
-<p class="paragraph"/>In Wicket we use class <code>org.apache.wicket.Session</code> to handle session-relative informations such as client informations, session attributes, session-level cache (seen in paragraph 6.2.4), etc...<p class="paragraph"/>In addition, we know from paragraph 6.1 that Wicket creates a user session to store versions of stateful pages. Similarly to what happens with RequestCycle, the new Session's instances are generated by the <code>Application</code> class with the <code>newSession(Request request, Response response)</code> method. This method is not declared as final, hence it can be overridden if we need to use a custom implementation of the Session class.<p class="paragraph"/>By default if our custom application class is a subclass of WebApplication, method newSession will return an instance of class <code>org.apache.wicket.protocol.http.WebSession</code>. As we have mentioned talking about <code>RequestCycle</code>, also class Session provides a static <c
ode>get()</code> method which returns the session associated to the current thread.<p class="paragraph"/><h3>Session and listeners</h3><p class="paragraph"/>Similar to the <code>RequestCycle</code>, class <code>org.apache.wicket.Session</code> also offers support for listener entities. With Session these entities must implement the callback interface <code>org.apache.wicket.ISessionListener</code> which exposes only the <code>onCreated(Session session)</code> method. As you might guess from its name, this method is called when a new session is created. Session listeners must be added to our application using a typed collection, just like we have done before with request cycle listeners:<p class="paragraph"/><div class="code"><pre>@Override
+<p class="paragraph"/>In Wicket we use class <code>org.apache.wicket.Session</code> to handle session-relative informations such as client informations, session attributes, session-level cache (seen in paragraph 8.2), etc...<p class="paragraph"/>In addition, we know from paragraph 8.1 that Wicket creates a user session to store versions of stateful pages. Similarly to what happens with RequestCycle, the new Session's instances are generated by the <code>Application</code> class with the <code>newSession(Request request, Response response)</code> method. This method is not declared as final, hence it can be overridden if we need to use a custom implementation of the Session class.<p class="paragraph"/>By default if our custom application class is a subclass of WebApplication, method newSession will return an instance of class <code>org.apache.wicket.protocol.http.WebSession</code>. As we have mentioned talking about <code>RequestCycle</code>, also class Session provides a static <cod
e>get()</code> method which returns the session associated to the current thread.<p class="paragraph"/><h3>Session and listeners</h3><p class="paragraph"/>Similar to the <code>RequestCycle</code>, class <code>org.apache.wicket.Session</code> also offers support for listener entities. With Session these entities must implement the callback interface <code>org.apache.wicket.ISessionListener</code> which exposes only the <code>onCreated(Session session)</code> method. As you might guess from its name, this method is called when a new session is created. Session listeners must be added to our application using a typed collection, just like we have done before with request cycle listeners:<p class="paragraph"/><div class="code"><pre>@Override
<span class="java-keyword">public</span> void init(){<p class="paragraph"/> <span class="java-keyword">super</span>.init();<p class="paragraph"/> //listener initialization…
ISessionListener myListener;
//add a custom session listener
@@ -1294,7 +1294,7 @@ Remember that invalidateNow() will immed
<h2 id="chapter8_5">9.5 Summary</h2>
-<p class="paragraph"/>In this chapter we had a look at how Wicket internally handles a web request. Even if most of the time we won't need to customize this internal process, knowing how it works is essential to use the framework at 100%.<p class="paragraph"/>Entities like Application and Session will come in handy again when we will tackle the topic of security in chapter 18.
+<p class="paragraph"/>In this chapter we had a look at how Wicket internally handles a web request. Even if most of the time we won't need to customize this internal process, knowing how it works is essential to use the framework at 100%.<p class="paragraph"/>Entities like Application and Session will come in handy again when we will tackle the topic of security in chapter 20.
<h1 id="chapter9">10 Wicket Links and URL generation</h1>
@@ -1520,7 +1520,7 @@ Java code:<p class="paragraph"/><div cla
};
add(form);</pre></div><p class="paragraph"/>Method onSubmit is called whenever a form has been submitted and it can be overridden to perform custom actions. Please note that a Wicket form can be submitted using a standard HTML submit button which is not mapped to any component (i.e. it does not have a wicket:id attribute).
In the next chapter we will continue to explore Wicket forms and we will see how to submit forms using special components which implement interface <code>org.apache.wicket.markup.html.form.IFormSubmitter</code>.<p class="paragraph"/><h3>Form and models</h3><p class="paragraph"/>A form should contain some input fields (like text fields, check boxes, radio buttons, drop-down lists, text areas, etc.) to interact with users. Wicket provides an abstraction for all these kinds of elements with component org.apache.wicket.markup.html.form.FormComponent:<p class="paragraph"/><img border="0" class="center" src="../img/uml-form-component.png"></img><p class="paragraph"/>The purpose of FormComponent is to store the corresponding user input into its model when the form is submitted. The form is responsible for mapping input values to the corresponding components, avoiding us the burden of manually synchronizing models with input fields and vice versa.<p class="paragraph"/><h3>Login form</h3><p
class="paragraph"/>As first example of interaction between the form and its models, we will build a classic login form which asks for username and password (project LoginForm).<p class="paragraph"/><blockquote class="warning">
-The topic of security will be discussed later in chapter 18. The following form is for example purposes only and is not suited for a real application.
+The topic of security will be discussed later in chapter 20. The following form is for example purposes only and is not suited for a real application.
If you need to use a login form you should consider to use component <code>org.apache.wicket.authroles.authentication.panel.SignInPanel</code> shipped with Wicket.
</blockquote><p class="paragraph"/>This form needs two text fields, one of which must be a password field. We should also use a label to display the result of login process1. For the sake of simplicity, the login logic is all inside onSubmit and is quite trivial.<p class="paragraph"/>The following is a possible implementation of our form:<p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> class LoginForm <span class="java-keyword">extends</span> Form {<p class="paragraph"/> <span class="java-keyword">private</span> TextField usernameField;
<span class="java-keyword">private</span> PasswordTextField passwordField;
@@ -3412,14 +3412,14 @@ Since both <code>restartResponseAtSignIn
getSecuritySettings().
setAuthorizationStrategy(myAuthorizationStrategy);
}
-//...</pre></div><p class="paragraph"/>If we want to combine the action of two or more authorization strategies we can chain them with strategy <code>CompoundAuthorizationStrategy</code> which implements composite patter for authorization strategies.<p class="paragraph"/>Most of the times we won't need to implement an <code>IAuthorizationStrategy</code> from scratch as Wicket already comes with a set of built-in strategies. In the next paragraphs we will see some of these strategies that can be used to implement an effective and flexible security policy.<p class="paragraph"/><h3>SimplePageAuthorizationStrategy</h3><p class="paragraph"/>Abstract class SimplePageAuthorizationStrategy (in package <code>org.apache.wicket.authorization.strategies.page</code>) is a strategy that checks user authorizations calling abstract method <code>isAuthorized</code> only for those pages that are subclasses of a given supertype. If <code>isAuthorized</code> returns false, the user is redirected to the
sign in page specified as second constructor parameter:<p class="paragraph"/><div class="code"><pre>SimplePageAuthorizationStrategy authorizationStrategy = <span class="java-keyword">new</span> SimplePageAuthorizationStrategy(
+//...</pre></div><p class="paragraph"/>If we want to combine the action of two or more authorization strategies we can chain them with strategy <code>CompoundAuthorizationStrategy</code> which implements composite pattern for authorization strategies.<p class="paragraph"/>Most of the times we won't need to implement an <code>IAuthorizationStrategy</code> from scratch as Wicket already comes with a set of built-in strategies. In the next paragraphs we will see some of these strategies that can be used to implement an effective and flexible security policy.<p class="paragraph"/><h3>SimplePageAuthorizationStrategy</h3><p class="paragraph"/>Abstract class SimplePageAuthorizationStrategy (in package <code>org.apache.wicket.authorization.strategies.page</code>) is a strategy that checks user authorizations calling abstract method <code>isAuthorized</code> only for those pages that are subclasses of a given supertype. If <code>isAuthorized</code> returns false, the user is redirected to th
e sign in page specified as second constructor parameter:<p class="paragraph"/><div class="code"><pre>SimplePageAuthorizationStrategy authorizationStrategy = <span class="java-keyword">new</span> SimplePageAuthorizationStrategy(
PageClassToCheck.class, SignInPage.class)
{
<span class="java-keyword">protected</span> <span class="java-object">boolean</span> isAuthorized()
{
//Authentication code…
}
-};</pre></div><p class="paragraph"/>By default <code>SimplePageAuthorizationStrategy</code> checks for permissions only on pages. If we want to change this behavior and check also other kinds of components, we must override method <code>isActionAuthorized</code> and implement our custom logic inside it.<p class="paragraph"/><h3>Role-based strategies</h3><p class="paragraph"/>At the end of paragraph 18.1.1 we have introduced AbstractAuthenticatedWebSession's method getRoles which is provided to support role-based authorization returning the set of roles granted to the current user.<p class="paragraph"/>In Wicket roles are simple strings like âBASIC_USERâ or âADMINâ (they don't need to be capitalized) and they are handled with class <code>org.apache.wicket.authroles.authorization.strategies.role.Roles</code>. This class extends standard HashSet collection adding some functionalities to check whether the set contains one or more roles. Class <code>Roles</code>
already defines roles Roles.USER and Roles.ADMIN.<p class="paragraph"/>The session class in the following example returns a custom âSIGNED_INâ role for every authenticated user and it adds an Roles.ADMIN role if username is equal to superuser:<p class="paragraph"/><div class="code"><pre>class BasicAuthenticationRolesSession <span class="java-keyword">extends</span> AuthenticatedWebSession {
+};</pre></div><p class="paragraph"/>By default <code>SimplePageAuthorizationStrategy</code> checks for permissions only on pages. If we want to change this behavior and check also other kinds of components, we must override method <code>isActionAuthorized</code> and implement our custom logic inside it.<p class="paragraph"/><h3>Role-based strategies</h3><p class="paragraph"/>At the end of paragraph 20.1 we have introduced AbstractAuthenticatedWebSession's method getRoles which is provided to support role-based authorization returning the set of roles granted to the current user.<p class="paragraph"/>In Wicket roles are simple strings like âBASIC_USERâ or âADMINâ (they don't need to be capitalized) and they are handled with class <code>org.apache.wicket.authroles.authorization.strategies.role.Roles</code>. This class extends standard HashSet collection adding some functionalities to check whether the set contains one or more roles. Class <code>Roles</code> al
ready defines roles Roles.USER and Roles.ADMIN.<p class="paragraph"/>The session class in the following example returns a custom âSIGNED_INâ role for every authenticated user and it adds an Roles.ADMIN role if username is equal to superuser:<p class="paragraph"/><div class="code"><pre>class BasicAuthenticationRolesSession <span class="java-keyword">extends</span> AuthenticatedWebSession {
<span class="java-keyword">private</span> <span class="java-object">String</span> userName;<p class="paragraph"/> <span class="java-keyword">public</span> BasicAuthenticationRolesSession(Request request) {
<span class="java-keyword">super</span>(request);
}<p class="paragraph"/> @Override
@@ -3433,7 +3433,7 @@ Since both <code>restartResponseAtSignIn
resultRoles.add(Roles.ADMIN);<p class="paragraph"/> <span class="java-keyword">return</span> resultRoles;
}
}</pre></div><p class="paragraph"/>Roles can be adopted to apply security restrictions on our pages and components. This can be done using one of the two built-in authorization strategies that extend super class <code>AbstractRoleAuthorizationStrategyWicket</code>: <code>MetaDataRoleAuthorizationStrategy</code> and <code>AnnotationsRoleAuthorizationStrategy</code><p class="paragraph"/>The difference between these two strategies is that <code>MetaDataRoleAuthorizationStrategy</code> handles role-based authorizations with Wicket metadata while <code>AnnotationsRoleAuthorizationStrategy</code> uses Java annotations.<p class="paragraph"/><blockquote class="note">
-Application class <code>AuthenticatedWebApplication</code> already sets <code>MetaDataRoleAuthorizationStrategy</code> and <code>AnnotationsRoleAuthorizationStrategy</code> as its own authorization strategies (it uses a compound strategy as we will see in paragraph 18.2.4).<p class="paragraph"/>The code that we will see in the next examples is for illustrative purpose only. If our application class inherits from <code>AuthenticatedWebApplication</code> we won't need to configure anything to use these two strategies.
+Application class <code>AuthenticatedWebApplication</code> already sets <code>MetaDataRoleAuthorizationStrategy</code> and <code>AnnotationsRoleAuthorizationStrategy</code> as its own authorization strategies (it uses a compound strategy as we will see in paragraph 20.2).<p class="paragraph"/>The code that we will see in the next examples is for illustrative purpose only. If our application class inherits from <code>AuthenticatedWebApplication</code> we won't need to configure anything to use these two strategies.
</blockquote><p class="paragraph"/><h4>Using roles with metadata</h4><p class="paragraph"/>Strategy <code>MetaDataRoleAuthorizationStrategy</code> uses application and components metadata to implement role-based authorizations. The class defines a set of static methods authorize that can be used to specify which roles are allowed to instantiate a component and which roles can perform a given action on a component.<p class="paragraph"/>The following code snippet reports both application and session classes from project <code>MetaDataRolesStrategyExample</code> and illustrates how to use <code>MetaDataRoleAuthorizationStrategy</code> to allow access to a given page (AdminOnlyPage) only to ADMIN role:<p class="paragraph"/><strong class="bold">Application class:</strong><p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> class WicketApplication <span class="java-keyword">extends</span> AuthenticatedWebApplication{
@Override
<span class="java-keyword">public</span> <span class="java-object">Class</span><? <span class="java-keyword">extends</span> WebPage> getHomePage(){
@@ -3529,7 +3529,7 @@ Application class <code>AuthenticatedWeb
<li>patterns start with either a "+" or a "-". In the first case the pattern will add one or more file to the set while starting a pattern with a â-â we exclude all the files matching the given pattern. For example pattern â-web.xmlâ excludes all web.xml files in all directories.</li>
<li>wildcard character â*â is supported as placeholder for zero or more characters. For example pattern â+*.mp4â adds all the mp4 files inside all directories.</li>
<li>subdirectories are supported as well. For example pattern â+documents/*.pdfâ adds all pdf files under âdocumentsâ directory. Character â*â can be used with directories to specify a nesting level. For example â+documents/*/*.pdfâ adds all pdf files placed one level below âdocumentsâ directory.</li>
-<li>a double wildcard character â**â indicates zero or more subdirectories. For example patter â+documents/**/*.pdfâ adds all pdf files placed inside âdocumentsâ directory or inside any of its subdirectories.</li>
+<li>a double wildcard character â**â indicates zero or more subdirectories. For example pattern â+documents/**/*.pdfâ adds all pdf files placed inside âdocumentsâ directory or inside any of its subdirectories.</li>
</ul><p class="paragraph"/>Patterns that allow to access to every file with a given extensions (such as â+*.pdfâ) should be always avoided in favour of more restrictive expressions that contain a directory structure:<p class="paragraph"/><div class="code"><pre>//Application class code…
@Override
<span class="java-keyword">public</span> void init()
Modified: wicket/common/site/trunk/_site/guide/guide/single.pdf
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/single.pdf?rev=1552439&r1=1552438&r2=1552439&view=diff
==============================================================================
Binary files - no diff available.
Modified: wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter10/chapter10_3.gdoc
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter10/chapter10_3.gdoc?rev=1552439&r1=1552438&r2=1552439&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter10/chapter10_3.gdoc (original)
+++ wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter10/chapter10_3.gdoc Thu Dec 19 21:43:37 2013
@@ -39,7 +39,7 @@ h3. Login form
As first example of interaction between the form and its models, we will build a classic login form which asks for username and password (project LoginForm).
{warning}
-The topic of security will be discussed later in chapter 18. The following form is for example purposes only and is not suited for a real application.
+The topic of security will be discussed later in chapter 20. The following form is for example purposes only and is not suited for a real application.
If you need to use a login form you should consider to use component @org.apache.wicket.authroles.authentication.panel.SignInPanel@ shipped with Wicket.
{warning}
Modified: wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter19/chapter19_2.gdoc
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter19/chapter19_2.gdoc?rev=1552439&r1=1552438&r2=1552439&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter19/chapter19_2.gdoc (original)
+++ wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter19/chapter19_2.gdoc Thu Dec 19 21:43:37 2013
@@ -47,7 +47,7 @@ To change the authorization strategy in
//...
{code}
-If we want to combine the action of two or more authorization strategies we can chain them with strategy @CompoundAuthorizationStrategy@ which implements composite patter for authorization strategies.
+If we want to combine the action of two or more authorization strategies we can chain them with strategy @CompoundAuthorizationStrategy@ which implements composite pattern for authorization strategies.
Most of the times we won't need to implement an @IAuthorizationStrategy@ from scratch as Wicket already comes with a set of built-in strategies. In the next paragraphs we will see some of these strategies that can be used to implement an effective and flexible security policy.
@@ -70,7 +70,7 @@ By default @SimplePageAuthorizationStrat
h3. Role-based strategies
-At the end of paragraph 18.1.1 we have introduced AbstractAuthenticatedWebSession's method getRoles which is provided to support role-based authorization returning the set of roles granted to the current user.
+At the end of paragraph 20.1 we have introduced AbstractAuthenticatedWebSession's method getRoles which is provided to support role-based authorization returning the set of roles granted to the current user.
In Wicket roles are simple strings like âBASIC_USERâ or âADMINâ (they don't need to be capitalized) and they are handled with class @org.apache.wicket.authroles.authorization.strategies.role.Roles@. This class extends standard HashSet collection adding some functionalities to check whether the set contains one or more roles. Class @Roles@ already defines roles Roles.USER and Roles.ADMIN.
@@ -116,7 +116,7 @@ Roles can be adopted to apply security r
The difference between these two strategies is that @MetaDataRoleAuthorizationStrategy@ handles role-based authorizations with Wicket metadata while @AnnotationsRoleAuthorizationStrategy@ uses Java annotations.
{note}
-Application class @AuthenticatedWebApplication@ already sets @MetaDataRoleAuthorizationStrategy@ and @AnnotationsRoleAuthorizationStrategy@ as its own authorization strategies (it uses a compound strategy as we will see in paragraph 18.2.4).
+Application class @AuthenticatedWebApplication@ already sets @MetaDataRoleAuthorizationStrategy@ and @AnnotationsRoleAuthorizationStrategy@ as its own authorization strategies (it uses a compound strategy as we will see in paragraph 20.2).
The code that we will see in the next examples is for illustrative purpose only. If our application class inherits from @AuthenticatedWebApplication@ we won't need to configure anything to use these two strategies.
{note}
Modified: wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter19/chapter19_4.gdoc
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter19/chapter19_4.gdoc?rev=1552439&r1=1552438&r2=1552439&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter19/chapter19_4.gdoc (original)
+++ wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter19/chapter19_4.gdoc Thu Dec 19 21:43:37 2013
@@ -20,7 +20,7 @@ To modify the set of allowed files forma
* patterns start with either a "+" or a "-". In the first case the pattern will add one or more file to the set while starting a pattern with a â-â we exclude all the files matching the given pattern. For example pattern â-web.xmlâ excludes all web.xml files in all directories.
* wildcard character â\*â is supported as placeholder for zero or more characters. For example pattern â+\*.mp4â adds all the mp4 files inside all directories.
* subdirectories are supported as well. For example pattern â+documents/\*.pdfâ adds all pdf files under âdocumentsâ directory. Character â\*â can be used with directories to specify a nesting level. For example â+documents/\*/\*.pdfâ adds all pdf files placed one level below âdocumentsâ directory.
-* a double wildcard character â\*\*â indicates zero or more subdirectories. For example patter â+documents/\*\*/\*.pdfâ adds all pdf files placed inside âdocumentsâ directory or inside any of its subdirectories.
+* a double wildcard character â\*\*â indicates zero or more subdirectories. For example pattern â+documents/\*\*/\*.pdfâ adds all pdf files placed inside âdocumentsâ directory or inside any of its subdirectories.
Patterns that allow to access to every file with a given extensions (such as â+\*.pdfâ) should be always avoided in favour of more restrictive expressions that contain a directory structure:
Modified: wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter4/chapter4_2.gdoc
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter4/chapter4_2.gdoc?rev=1552439&r1=1552438&r2=1552439&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter4/chapter4_2.gdoc (original)
+++ wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter4/chapter4_2.gdoc Thu Dec 19 21:43:37 2013
@@ -4,7 +4,7 @@ One of the goals of Wicket is to overcom
h3. Markup inheritance
As we have seen in the previous chapter, Wicket pages are pure Java classes, so we can easily write a page which is a subclass of another parent page. But in Wicket inheritance is not limited to the classic object-oriented code inheritance. When a class subclasses a @WebPage@ it also inherits the HTML file of to the parent class. This type of inheritance is called markup inheritance.
-To better illustrate this concept let's consider the following example where we have a page class called @GenericSitePage@ with the corresponding HTML file GenericSitePage.html. Now let's create a specific page called @OrderCheckOutPage@ where users can check out their orders on our our web site. This class extends @GenericSitePage@ but we don't provide it with any corresponding HTML file.
+To better illustrate this concept let's consider the following example where we have a page class called @GenericSitePage@ with the corresponding HTML file GenericSitePage.html. Now let's create a specific page called @OrderCheckOutPage@ where users can check out their orders on our web site. This class extends @GenericSitePage@ but we don't provide it with any corresponding HTML file.
In this scenario @OrderCheckOutPage@ will use GenericSitePage.html as markup file:
!markup-inheritance.png!
Modified: wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter5/chapter5_9.gdoc
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter5/chapter5_9.gdoc?rev=1552439&r1=1552438&r2=1552439&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter5/chapter5_9.gdoc (original)
+++ wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter5/chapter5_9.gdoc Thu Dec 19 21:43:37 2013
@@ -12,7 +12,7 @@ Wicket comes with a nice utility tag cal
</wicket:enclosure>
{code}
-Now if component @totalAmount@ is not visible, its description (@Total amount:@) will be automatically hidden. If we have more then a Wicket component inside @<wicket:enclosure>@ we can use @child@ attribute to specify which component will control the overall visibility:
+Now if component @totalAmount@ is not visible, its description (@Total amount:@) will be automatically hidden. If we have more than a Wicket component inside @<wicket:enclosure>@ we can use @child@ attribute to specify which component will control the overall visibility:
{code:html}
<wicket:enclosure child="totalAmount">
Modified: wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter7/chapter7_1.gdoc
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter7/chapter7_1.gdoc?rev=1552439&r1=1552438&r2=1552439&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter7/chapter7_1.gdoc (original)
+++ wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter7/chapter7_1.gdoc Thu Dec 19 21:43:37 2013
@@ -1,9 +1,9 @@
-Wicket pages can be divided into two categories: stateful and stateless pages. Stateful pages are those which rely on user session to store they internal state and to keep track of user interaction.
+Wicket pages can be divided into two categories: stateful and stateless pages. Stateful pages are those which rely on user session to store their internal state and to keep track of user interaction.
On the contrary stateless pages are those which don't change their internal state during their lifecycle and they don't need to occupy space into user session.
From Wicket's point of view the biggest difference between these two types of page is that stateful pages are versioned, meaning that they will be saved into user session every time their internal state has changed. Wicket automatically assigns a session to the user the first time a stateful page is requested. Page versions are stored into user session using Java Serialization mechanism.
Stateless pages are never versioned and that's why they don't require a valid user session. If we want to know whether a page is stateless or not, we can call the isPageStateless() method of class Page.
-In order to build a stateless page we must comply with some rules to ensure that the page won't need to use user session. These rules are illustrated in paragraph 6.3 but before talking about stateless pages we must first understand how stateful pages are handled and why they are versioned.
\ No newline at end of file
+In order to build a stateless page we must comply with some rules to ensure that the page won't need to use user session. These rules are illustrated in paragraph 8.3 but before talking about stateless pages we must first understand how stateful pages are handled and why they are versioned.
\ No newline at end of file
Modified: wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter7/chapter7_2.gdoc
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter7/chapter7_2.gdoc?rev=1552439&r1=1552438&r2=1552439&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter7/chapter7_2.gdoc (original)
+++ wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter7/chapter7_2.gdoc Thu Dec 19 21:43:37 2013
@@ -50,7 +50,7 @@ For more details about page storing you
On this page you can find which classes are involved into page storing mechanism and how they work together.
{note}
-As we have stated at the beginning of this chapter, page versions are stored using Java serialization, therefore every object referenced inside a page must be serializable1. In paragraph 9.6 we will see how to overcome this limit and work with non-serializable objects in our components using detachable Wicket models.
+As we have stated at the beginning of this chapter, page versions are stored using Java serialization, therefore every object referenced inside a page must be serializable. In paragraph 9.6 we will see how to overcome this limit and work with non-serializable objects in our components using detachable Wicket models.
h3. Using a specific page version with PageReference
Modified: wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter7/chapter7_4.gdoc
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter7/chapter7_4.gdoc?rev=1552439&r1=1552438&r2=1552439&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter7/chapter7_4.gdoc (original)
+++ wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter7/chapter7_4.gdoc Thu Dec 19 21:43:37 2013
@@ -2,4 +2,4 @@
In this chapter we have seen how page instances are managed by Wicket. We have learnt that pages can be divided into two families: stateless and stateful pages. Knowing the difference between the two types of pages is important to build the right page for a given task.
-However, to complete the discussion about stateless pages we still have to deal with two topics we have just outlined in this chapter: class PageParameters and bookmarkable pages. The first part of chapter 8 will cover these missing topics.
\ No newline at end of file
+However, to complete the discussion about stateless pages we still have to deal with two topics we have just outlined in this chapter: class PageParameters and bookmarkable pages. The first part of chapter 10 will cover these missing topics.
\ No newline at end of file
Modified: wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter8/chapter8_3.gdoc
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter8/chapter8_3.gdoc?rev=1552439&r1=1552438&r2=1552439&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter8/chapter8_3.gdoc (original)
+++ wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter8/chapter8_3.gdoc Thu Dec 19 21:43:37 2013
@@ -32,7 +32,7 @@ The following sequence diagram recaps ho
!request-cycle-handler.png!
-Developers can create additional implementations of IRequestMapper and add them to their application via the mount(IRequestMapper mapper) method of the WebApplication class. In paragraph 8.6 we will see how Wicket uses this method to add built-in mappers for mounted pages.
+Developers can create additional implementations of IRequestMapper and add them to their application via the mount(IRequestMapper mapper) method of the WebApplication class. In paragraph 10.6 we will see how Wicket uses this method to add built-in mappers for mounted pages.
h3. Generating URL with the urlFor and mapUrlFor methods
@@ -59,7 +59,7 @@ h3. RequestCycle's hook methods and list
The RequestCycle comes with some hook methods which can be overridden to perform custom actions when request handling reaches a specific stage. These methods are:
* *onBeginRequest():* called when the RequestCycle is about to start handling the request.
* *onEndRequest():* called when the RequestCycle has finished to handle the request
-* *onDetach():* called after the request handling has completed and the RequestCycle is about to be detached from its thread. The default implementation of this method invokes detach() on the current session (the Session class will be shortly discussed in paragraph 7.4).
+* *onDetach():* called after the request handling has completed and the RequestCycle is about to be detached from its thread. The default implementation of this method invokes detach() on the current session (the Session class will be shortly discussed in paragraph 9.4).
Methods onBeforeRequest and onEndRequest can be used if we need to execute custom actions before and after business code is executed, such as opening a Hibernate/JPA session and closing it when code has terminated.
Modified: wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter8/chapter8_4.gdoc
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter8/chapter8_4.gdoc?rev=1552439&r1=1552438&r2=1552439&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter8/chapter8_4.gdoc (original)
+++ wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter8/chapter8_4.gdoc Thu Dec 19 21:43:37 2013
@@ -1,8 +1,8 @@
-In Wicket we use class @org.apache.wicket.Session@ to handle session-relative informations such as client informations, session attributes, session-level cache (seen in paragraph 6.2.4), etc...
+In Wicket we use class @org.apache.wicket.Session@ to handle session-relative informations such as client informations, session attributes, session-level cache (seen in paragraph 8.2), etc...
-In addition, we know from paragraph 6.1 that Wicket creates a user session to store versions of stateful pages. Similarly to what happens with RequestCycle, the new Session's instances are generated by the @Application@ class with the @newSession(Request request, Response response)@ method. This method is not declared as final, hence it can be overridden if we need to use a custom implementation of the Session class.
+In addition, we know from paragraph 8.1 that Wicket creates a user session to store versions of stateful pages. Similarly to what happens with RequestCycle, the new Session's instances are generated by the @Application@ class with the @newSession(Request request, Response response)@ method. This method is not declared as final, hence it can be overridden if we need to use a custom implementation of the Session class.
By default if our custom application class is a subclass of WebApplication, method newSession will return an instance of class @org.apache.wicket.protocol.http.WebSession@. As we have mentioned talking about @RequestCycle@, also class Session provides a static @get()@ method which returns the session associated to the current thread.
Modified: wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter8/chapter8_5.gdoc
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter8/chapter8_5.gdoc?rev=1552439&r1=1552438&r2=1552439&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter8/chapter8_5.gdoc (original)
+++ wicket/common/site/trunk/_site/guide/guide/src/docs/guide/chapter8/chapter8_5.gdoc Thu Dec 19 21:43:37 2013
@@ -2,4 +2,4 @@
In this chapter we had a look at how Wicket internally handles a web request. Even if most of the time we won't need to customize this internal process, knowing how it works is essential to use the framework at 100%.
-Entities like Application and Session will come in handy again when we will tackle the topic of security in chapter 18.
\ No newline at end of file
+Entities like Application and Session will come in handy again when we will tackle the topic of security in chapter 20.
\ No newline at end of file