[
https://issues.apache.org/jira/browse/WICKET-5451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Del Bene resolved WICKET-5451.
-------------------------------------
Resolution: Fixed
> Minor typos and reference errors paragraph 5 - 9
> ------------------------------------------------
>
> Key: WICKET-5451
> URL: https://issues.apache.org/jira/browse/WICKET-5451
> Project: Wicket
> Issue Type: Improvement
> Components: guide
> Affects Versions: 6.12.0
> Environment: http://wicket.apache.org/guide/guide/
> Reporter: Alica Moser
> Assignee: Andrea Del Bene
> Priority: Minor
>
> 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>
> {code}
>
> -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));
> {code}
>
> -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 @@
> 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!
> 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>
> {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">
> @@ -30,4 +30,4 @@
> </div>
> <label>Expected delivery date: </label><span
> wicket:id="delivDate"></span>
> </wicket:enclosure>
> -{code}
> \ No newline at end of file
> +{code}
> 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.
>
> h3. 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 @@
>
> !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 @@
> 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.
>
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
