[WICKET-5451] Minor typos and reference errors paragraph 5 - 9

• Type: Improvement
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 6.12.0
• Component/s: guide
• Environment: http://wicket.apache.org/guide/guide/
• Assignee: Andrea Del Bene
• Reporter: Alica Moser
• Created: 18/Dec/13 09:09
• Updated: 19/Dec/13 21:42
• Resolved: 19/Dec/13 21:42

Description

corrected minor typos and reference errors. svn diff:

Index: docs/guide/chapter10/chapter10_2.gdoc
===================================================================
— docs/guide/chapter10/chapter10_2.gdoc (revision 1551496)
+++ docs/guide/chapter10/chapter10_2.gdoc (working copy)
@@ -112,5 +112,5 @@
CompoundPropertyModel are particularly useful when used in combination with Wicket forms, as we will see in the next paragraph.

{note}
-Model is referred to as static model because the result of its method getObject is fixed an it is not dynamically evaluated each time the method is called. In contrast, models like PropertyModel and CompoundProperty Model are called dynamic models.
+Model is referred to as static model because the result of its method getObject is fixed and it is not dynamically evaluated each time the method is called. In contrast, models like PropertyModel and CompoundProperty Model are called dynamic models.
{note}

\ No newline at end of file
Index: docs/guide/chapter10/chapter10_4.gdoc
===================================================================
— docs/guide/chapter10/chapter10_4.gdoc (revision 1551496)
+++ docs/guide/chapter10/chapter10_4.gdoc (working copy)
@@ -38,7 +38,7 @@
</select>

 
-The first option is a placeholder item corresponding to a null model value. By default DropDownChoice cannot have a null value so users are forced to select a not-null option. If we want to change this behavior we can set the nullValid flag to true via the setNullValid method. Please note that the placeholder text (“Chose one”) can be localized, as we will see in chapter 12. The other options are identified by the attribute value. By default the value of this attribute is the index of the single option inside the provided list of choices, while the text displayed to the user is obtained by  calling toString()on the choice object. This default behavior works fine as long as our options are simple objects like strings, but when we move to more complex objects we may need to implement a more sophisticated algorithm to generate the value to use as the option id and the one to display to user. Wicket has solved this problem with @org.apache.wicket.markup.html.form.IChoiceRender@ interface. This interface defines method getDisplayValue(T object) that is called to generate the value to display for the given choice object, and method getIdValue(T object, int index) that is called to generate the option id. The built-in implementation of this interface is class @org.apache.wicket.markup.html.form.ChoiceRenderer@ which renders the two values using property expressions.
+The first option is a placeholder item corresponding to a null model value. By default DropDownChoice cannot have a null value so users are forced to select a not-null option. If we want to change this behavior we can set the nullValid flag to true via the setNullValid method. Please note that the placeholder text (“Chose one”) can be localized, as we will see in chapter 14. The other options are identified by the attribute value. By default the value of this attribute is the index of the single option inside the provided list of choices, while the text displayed to the user is obtained by  calling toString()on the choice object. This default behavior works fine as long as our options are simple objects like strings, but when we move to more complex objects we may need to implement a more sophisticated algorithm to generate the value to use as the option id and the one to display to user. Wicket has solved this problem with @org.apache.wicket.markup.html.form.IChoiceRender@ interface. This interface defines method getDisplayValue(T object) that is called to generate the value to display for the given choice object, and method getIdValue(T object, int index) that is called to generate the option id. The built-in implementation of this interface is class @org.apache.wicket.markup.html.form.ChoiceRenderer@ which renders the two values using property expressions.
 
 In the following code we want to show a list of Person objects using their full name as value to display and using their passport code as option id: 
 
@@ -51,4 +51,4 @@
 form.add(new DropDownChoice<String>("persons", new Model<Person>(), persons, personRenderer));
 

-The choice renderer can be assigned to the DropDownChoice using one of its constructor that accepts this type of parameter (like we did in the example above) or after its creation invoking setChoiceRenderer method.
\ No newline at end of file
+The choice renderer can be assigned to the DropDownChoice using one of its constructor that accepts this type of parameter (like we did in the example above) or after its creation invoking setChoiceRenderer method.
Index: docs/guide/chapter4/chapter4_2.gdoc
===================================================================
— docs/guide/chapter4/chapter4_2.gdoc (revision 1551496)
+++ docs/guide/chapter4/chapter4_2.gdoc (working copy)
@@ -4,7 +4,7 @@

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:

Index: docs/guide/chapter5/chapter5_9.gdoc
===================================================================
— docs/guide/chapter5/chapter5_9.gdoc (revision 1551496)
+++ docs/guide/chapter5/chapter5_9.gdoc (working copy)
@@ -12,7 +12,7 @@
</wicket:enclosure>

 
-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"> 
@@ -30,4 +30,4 @@
     </div>
     <label>Expected delivery date: </label><span wicket:id="delivDate"></span>
 </wicket:enclosure>
-

\ No newline at end of file
+

Index: docs/guide/chapter7/chapter7_1.gdoc
===================================================================
— docs/guide/chapter7/chapter7_1.gdoc (revision 1551496)
+++ docs/guide/chapter7/chapter7_1.gdoc (working copy)
@@ -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.
Index: docs/guide/chapter7/chapter7_2.gdoc
===================================================================
— docs/guide/chapter7/chapter7_2.gdoc (revision 1551496)
+++ docs/guide/chapter7/chapter7_2.gdoc (working copy)
@@ -50,7 +50,7 @@
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.

Using a specific page version with PageReference

Index: docs/guide/chapter7/chapter7_4.gdoc
===================================================================
— docs/guide/chapter7/chapter7_4.gdoc (revision 1551496)
+++ docs/guide/chapter7/chapter7_4.gdoc (working copy)
@@ -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.
Index: docs/guide/chapter8/chapter8_3.gdoc
===================================================================
— docs/guide/chapter8/chapter8_3.gdoc (revision 1551496)
+++ docs/guide/chapter8/chapter8_3.gdoc (working copy)
@@ -32,7 +32,7 @@

-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.

Generating URL with the urlFor and mapUrlFor methods

@@ -59,7 +59,7 @@
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.

Index: docs/guide/chapter8/chapter8_4.gdoc
===================================================================
— docs/guide/chapter8/chapter8_4.gdoc (revision 1551496)
+++ docs/guide/chapter8/chapter8_4.gdoc (working copy)
@@ -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.