http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/layout/layout_3.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/layout/layout_3.gdoc 
b/wicket-user-guide/src/docs/guide/layout/layout_3.gdoc
new file mode 100644
index 0000000..4ebdb7f
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/layout/layout_3.gdoc
@@ -0,0 +1,162 @@
+Let's go back to our layout example. In [chapter 5.1|guide:layout_1] we have 
divided our layout in common areas that must be part of every page. Now we will 
build a reusable template page for our web application combining pages and 
panels. The code examples are from project MarkupInheritanceExample.
+
+h3. Panels and layout areas
+
+First, let's build a custom panel for each layout area (except for 'content' 
area). For example given the  header area
+
+!header-area.png!
+
+we can build a panel called @HeaderPanel@ with a related markup file called 
HeaderPanel.html containing the HTML for this area:
+
+{code:html}
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+...
+</head>
+<body>
+   <wicket:panel>
+      <table width="100%" style="border: 0px none;">
+      <tbody>
+    <tr>
+    <td>
+       <img alt="Jug4Tenda" src="wicketLayout_files/logo_jug4tenda.gif">
+     </td>
+      <td>
+    <h1>Gestione Anagrafica</h1>
+   </td>   
+      </tr>
+      </tbody>
+      </table>   
+   </wicket:panel>
+</body>
+<html>
+{code}
+
+The class for this panel simply extends base class @Panel@:
+
+{code}
+package helloWorld.layoutTenda;
+
+import org.apache.wicket.markup.html.panel.Panel;
+
+public class HeaderPanel extends Panel {
+
+       public HeaderPanel(String id) {
+               super(id);              
+       }
+}
+{code}
+
+For each layout area we will build a panel like the one above that holds the 
appropriate HTML markup. In the end we will have the following set of panels:
+
+* HeaderPanel 
+* FooterPanel
+* MenuPanel
+
+Content area will change from page to page, so we don't need a reusable panel 
for it.
+
+h3. Template page
+
+Now we can build a generic template page using our brand new panels. Its 
markup is quite straightforward :
+
+{code:html}
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 
+...
+<!--Include CSS-->
+...
+</head>
+<body>
+<div id="header" wicket:id="headerPanel">header</div>
+<div id="body">
+       <div id="menu" wicket:id="menuPanel">menu</div>
+       <div id="content" wicket:id="contentComponent">content</div>
+</div>
+<div id="footer" wicket:id="footerPanel">footer</div>
+</body>
+</html>
+{code}
+
+The HTML code for this page implements the generic left-menu layout of our 
site. You can note the 4 @<div>@ tags used as containers for the corresponding 
areas.
+The page class contains the code to physically assemble the page and panels:
+
+{code}
+package helloWorld.layoutTenda;
+
+import org.apache.wicket.markup.html.WebPage;
+import org.apache.wicket.Component;
+import org.apache.wicket.markup.html.basic.Label;
+
+public class JugTemplate extends WebPage {
+       public static final String CONTENT_ID = "contentComponent";
+
+       private Component headerPanel;
+       private Component menuPanel;
+       private Component footerPanel;
+ 
+              public JugTemplate(){
+               add(headerPanel = new HeaderPanel("headerPanel"));
+               add(menuPanel = new MenuPanel("menuPanel"));
+               add(footerPanel = new FooterPanel("footerPanel"));
+               add(new Label(CONTENT_ID, "Put your content here"));
+       }
+              
+             //getters for layout areas
+       //... 
+}
+{code}
+
+Done! Our template page is ready to be used. Now all the pages of our site 
will be subclasses of this parent page and they will inherit the layout and the 
HTML markup. They will only substitute the @Label@ inserted as content area 
with their custom content.
+
+h3. Final example
+
+As final example we will build the login page for our site. We will call it 
@SimpleLoginPage@. First, we need a panel containing the login form. This will 
be the content area of our page. We will call it @LoginPanel@ and the markup is 
the following:
+
+{code:html}
+<html>
+<head>
+</head>
+<body>
+   <wicket:panel>
+    <div style="margin: auto; width: 40%;">
+       <form  id="loginForm" method="get">
+         <fieldset id="login" class="center">
+            <legend >Login</legend>               
+            <span >Username: </span><input type="text" id="username"/><br/>    
                                                              
+            <span >Password: </span><input type="password" id="password" />
+            <p>
+               <input type="submit" name="login" value="login"/>
+            </p>
+         </fieldset>
+      </form>
+    </div>   
+   </wicket:panel>
+</body>
+</html>
+{code}
+
+The class for this panel just extends @Panel@ class so we won't see the 
relative code. The form of this panel is for illustrative purpose only. We will 
see how to work with Wicket forms in chapters [11|guide:modelsforms] and 
[12|guide:forms2]. Since this is a login page we don't want it to display the 
left menu area. That's not a big deal as @Component@ class exposes a method 
called @setVisible@ which sets whether the component and its children should be 
displayed. 
+
+The resulting Java code for the login page is the following:
+
+{code}
+package helloWorld.layoutTenda;
+import helloWorld.LoginPanel;
+import org.apache.wicket.event.Broadcast;
+import org.apache.wicket.event.IEventSink;
+
+public class SimpleLoginPage extends JugTemplate {
+       public SimpleLoginPage(){
+               super();                
+               replace(new LoginPanel(CONTENT_ID));
+               getMenuPanel().setVisible(false);
+       }
+}
+{code}
+
+Obviously this page doesn't come with a related markup file. You can see the 
final page in the following picture:
+
+!final-login-page.png!
+

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/layout/layout_4.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/layout/layout_4.gdoc 
b/wicket-user-guide/src/docs/guide/layout/layout_4.gdoc
new file mode 100644
index 0000000..068bf86
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/layout/layout_4.gdoc
@@ -0,0 +1,94 @@
+With Wicket we can apply markup inheritance using another approach based on 
the tag @<wicket:child>@. This tag is used inside the parent's markup to define 
where the children pages/panels can “inject” their custom markup extending 
the markup inherited from the parent component. 
+An example of a parent page using the tag @<wicket:child>@ is the following:
+
+{code:html}
+<html>
+<head>
+       <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 
+</head>
+<body>
+       This is parent body!
+       <wicket:child/>
+</body>
+</html>
+{code}
+
+The markup of a child page/panel must be placed inside the tag 
@<wicket:extend>@. Only the markup inside @<wicket:extend>@ will be included in 
final markup. Here is an example of child page markup:
+
+{code}
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 
+</head>
+<body>
+    <wicket:extend>
+          This is child body!
+       </wicket:extend>
+</body>
+</html>
+{code}
+
+Considering the two pages seen above, the final markup generated for child 
page will be the following:
+
+{code:html}
+<html>
+<head>
+       <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+</head>
+<body>
+       This is parent body!
+       <wicket:child>
+       <wicket:extend>
+           This is child body!
+          </wicket:extend>
+    </wicket:child>
+</body>
+</html>
+{code}
+
+h3. Our example revisited
+
+Applying @<wicket:child>@ tag to our layout example, we obtain the following 
markup for the main template page:
+
+{code:html}
+<html>
+<head>
+       <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 
+</head>
+<body>
+<div id="header" wicket:id="headerPanel">header</div>
+<div id="body">
+       <div id="menu" wicket:id="menuPanel">menu</div>
+       <wicket:child/>
+</div>
+<div id="footer" wicket:id="footerPanel">footer</div>
+</body>
+</html>
+{code}
+
+We have replaced the @<div>@ tag of the content area with the tag 
@<wicket:child>@. Going forward with our example we can build a login page 
creating class @SimpleLoginPage@ which extends the @JugTemplate@ page, but with 
a related markup file like this:
+
+{code:html}
+<html>
+<head>
+</head>
+<body>
+   <wicket:extend>
+    <div style="margin: auto; width: 40%;">
+       <form  id="loginForm" method="get">
+         <fieldset id="login" class="center">
+            <legend >Login</legend>               
+            <span >Username: </span><input type="text" id="username"/><br/>    
                                                              
+            <span >Password: </span><input type="password" id="password" />
+            <p>
+               <input type="submit" name="login" value="login"/>
+            </p>
+         </fieldset>
+      </form>
+    </div>   
+   </wicket:extend>
+</body>
+</html>
+{code}
+
+As we can see this approach doesn't require to create custom panels to use as 
content area and it can be useful if we don't have to handle a GUI with a high 
degree of complexity.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/layout/layout_5.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/layout/layout_5.gdoc 
b/wicket-user-guide/src/docs/guide/layout/layout_5.gdoc
new file mode 100644
index 0000000..6eb8a54
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/layout/layout_5.gdoc
@@ -0,0 +1,2 @@
+
+Wicket applies inheritance also to HTML markup making layout management much 
easier and less error-prone. Defining a master template page to use as base 
class for the other pages is a great way to build a consistent layout and use 
it across all the pages on the web site. During the chapter we have also 
introduced the @Panel@ component, a very important Wicket class that is 
primarily designed to let us divide our pages in smaller and reusable UI 
components.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/maven.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/maven.gdoc 
b/wicket-user-guide/src/docs/guide/maven.gdoc
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/maven.gdoc
@@ -0,0 +1 @@
+

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/maven/maven_1.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/maven/maven_1.gdoc 
b/wicket-user-guide/src/docs/guide/maven/maven_1.gdoc
new file mode 100644
index 0000000..7c05c81
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/maven/maven_1.gdoc
@@ -0,0 +1,46 @@
+
+
+As pointed out in the note at page 9, Wicket can be started in two modes, 
DEVELOPMENT and DEPLOYMENT. When we are in DEVELOPMENT mode Wicket warns us at 
application startup with the following message:
+
+{code}
+********************************************************************
+*** WARNING: Wicket is running in DEVELOPMENT mode.              ***
+***                               ^^^^^^^^^^^                    ***
+*** Do NOT deploy to your live server(s) without changing this.  ***
+*** See Application#getConfigurationType() for more information. ***
+********************************************************************
+{code}
+
+As we can read Wicket itself discourages us from using DEVELOPMENT mode into 
production environment. The running mode of our application can be configured 
in three different ways. The first one is adding a filter parameter inside 
deployment descriptor web.xml:
+
+{code:html}
+<filter>      
+       <filter-name>wicket.MyApp</filter-name>
+       
<filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
+       <init-param>
+               <param-name>applicationClassName</param-name>
+               <param-value>org.wicketTutorial.WicketApplication</param-value>
+       </init-param>
+       <init-param>
+            <param-name>configuration</param-name>
+            <param-value>deployment</param-value>
+       </init-param>
+</filter>
+{code}
+
+The additional parameter is written in bold. The same parameter can be also 
expressed as context parameter:
+
+{code:html}
+<context-param>
+    <param-name>configuration</param-name>
+    <param-value>deployment</param-value>
+</context-param>
+{code}
+
+The third way to set the running mode is using system property 
wicket.configuration. This parameter can be specified in the command line that 
starts up the server:
+
+{code}
+java -Dwicket.configuration=deployment ...
+{code}
+
+Remember that system properties overwrite other settings, so they are ideal to 
ensure that on production machine the running mode will be always set to 
DEPLOYMENT. 
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/maven/maven_2.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/maven/maven_2.gdoc 
b/wicket-user-guide/src/docs/guide/maven/maven_2.gdoc
new file mode 100644
index 0000000..95cb4d8
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/maven/maven_2.gdoc
@@ -0,0 +1,129 @@
+
+
+{note}
+In order to follow the instructions of this paragraph you must have Maven 
installed on your system. The installation of Maven is out of the scope of this 
guide but you can easily find an extensive documentation about it on Internet.
+Another requirement is a good Internet connection (a flat ADSL is enough) 
because Maven needs to connect to its central repository to download the 
required dependencies. 
+{note}
+
+
+h3. From Maven to our IDE
+
+Wicket project and its dependencies are managed using Maven1. This tool is 
very useful also when we want to create a new project based on Wicket from 
scratch. With a couple of shell commands we can generate a new project properly 
configured and ready to be imported into our favourite IDE.
+The main step to create such a project is to run the command which generates 
project's structure and its artifacts. If we are not familiar with Maven or we 
simply don't want to type this command by hand, we can use the utility form on 
Wicket site at 
"http://wicket.apache.org/start/quickstart.html":http://wicket.apache.org/start/quickstart.html
 :
+
+!quickstart-webpage.png!
+
+Here we have to specify the root package of our project (GroupId), the project 
name (ArtifactId) and which version of Wicket we want to use (Version).
+Once we have run the resulting command in the OS shell, we will have a new 
folder with the same name of the project (i.e the ArtifactId). Inside this 
folder we can find a file called pom.xml. This is the main file used by Maven 
to manage our project. For example, using “org.wicketTutorial” as GroupId 
and “MyProject” as ArtifactId, we would obtain the following artifacts:
+
+{code}
+ .\MyProject
+        |   pom.xml
+        |
+        \---src
+            +---main
+            |   +---java
+            |   |   \---org
+            |   |       \---wicketTutorial
+            |   |               HomePage.html
+            |   |               HomePage.java
+            |   |               WicketApplication.java
+            |   |
+            |   +---resources
+            |   |       log4j.properties
+            |   |
+            |   \---webapp
+            |       \---WEB-INF
+            |               web.xml
+            |
+            \---test
+                \---java
+                    \---org
+                        \---wicketTutorial
+                                TestHomePage.java
+
+{code}
+
+Amongst other things, file pom.xml contains a section delimited by tag 
<dependencies> which declares the dependencies of our project. By default the 
Maven archetype will add the following Wicket modules as dependencies:
+
+{code:xml}
+...
+<dependencies>
+       <!--  WICKET DEPENDENCIES -->
+       <dependency>
+               <groupId>org.apache.wicket</groupId>
+               <artifactId>wicket-core</artifactId>
+               <version>${wicket.version}</version>
+       </dependency>
+       <dependency>
+               <groupId>org.apache.wicket</groupId>
+               <artifactId>wicket-ioc</artifactId>
+               <version>${wicket.version}</version>
+       </dependency>
+       <!-- OPTIONAL DEPENDENCY
+       <dependency>
+               <groupId>org.apache.wicket</groupId>
+               <artifactId>wicket-extensions</artifactId>
+               <version>${wicket.version}</version>
+       </dependency>
+       --> 
+       ...
+</dependencies>
+...
+{code}
+
+If we need to use more Wicket modules or additional libraries, we can add the 
appropriate XML fragments here.
+
+h3. Importing a Maven project into our IDE
+
+Maven projects can be easily imported into the most popular Java IDEs. 
However, the procedure needed to do this differs from IDE to IDE. In this 
paragraph we can find the instructions to import Maven projects into three of 
the most popular IDEs among Java developers : NetBeans, JetBrains IDEA and 
Eclipse.
+
+*NetBeans*
+Starting from version 6.7, NetBeans includes Maven support, hence we can start 
it and directly open the folder containing our project:
+
+!netbeans-maven-import.png!
+
+*Intellj IDEA*
+Intellj IDEA comes with a Maven importing functionality that can be started 
under “File/New Project/Import from external model/Maven”. Then, we just 
have to select the pom.xml file of our project:
+
+!intellj-maven-import.png!
+
+*Eclipse*
+If our IDE is Eclipse the import procedure is a little more complex. Before 
opening the new project we must generate the Eclipse project artifacts running 
the following command from project root:
+
+{code}
+mvn eclipse:eclipse
+{code}
+
+  Now to import our project into Eclipse we must create a classpath variable 
called M2_REPO that must point to your local Maven repository. This can be done 
selecting “Window/Preferences” and searching for “Classpath Variables”. 
The folder containing our local Maven repository is usually under our user 
folder and is called .m2 (for example under Unix system is 
/home/<myUserName>/.m2/repository):
+
+!eclipse-classpath-variables.png!
+
+Once we have created the classpath variable we can go to 
“File/Import.../Existing Project into Workspace”, select the directory of 
the project and press “Finish”:
+
+!eclipse-maven-import.png!
+
+Once the project has been imported into Eclipse, we are free to use our 
favourite plug-ins to run it or debug it (like for example "run-jetty-run": 
http://code.google.com/p/run-jetty-run/ ).  
+
+{note}
+Please note the option “Copy projects into workspace” in the previous 
illustration. If we select it, the original project generated with Maven won't 
be affected by the changes made inside Eclipse because we will work on a copy 
of it under the current workspace.
+{note}
+
+{note}
+If we modify the pom.xml file (for example adding further dependencies) we 
must regenerate project's artifacts and refresh the project (F5 key) to reflect 
changes into Eclipse.
+{note}
+
+h3. Speeding up development with plugins.
+
+Now that we have our project loaded into our IDE we could start coding our 
components directly by hand. However it would be a shame to not leverage the 
free and good Wicket plugins available for our IDE. The following is a brief 
overview of the most widely used plugins for each of the three main IDEs 
considered so far.
+
+*NetBeans*
+NetBeans offers Wicket support thought 'NetBeans Plugin for Wicket' hosted at 
"http://java.net/projects/nbwicketsupport/":http://java.net/projects/nbwicketsupport/
 . This plugin is released under CDDL-1.0 license. 
+You can  find a nice introduction guide to this plugin at 
"http://netbeans.org/kb/docs/web/quickstart-webapps-wicket.html":http://netbeans.org/kb/docs/web/quickstart-webapps-wicket.html
 .
+
+*Intellj IDEA*
+For JetBrain IDEA we can use WicketForge plugin, hosted at Google Code 
"http://code.google.com/p/wicketforge/":http://code.google.com/p/wicketforge/ . 
The plugin is released under ASF 2.0 license.
+
+*Eclipse*
+With Eclipse we can install one of the plugins that supports Wicket. As of the 
writing of this document, the most popular is probably Qwickie, available in 
the Eclipse Marketplace and hosted on Google Code at 
"http://code.google.com/p/qwickie/":http://code.google.com/p/qwickie/ .
+QWickie is released under ASF 2.0 license.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/modelsforms.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/modelsforms.gdoc 
b/wicket-user-guide/src/docs/guide/modelsforms.gdoc
new file mode 100644
index 0000000..392dca4
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/modelsforms.gdoc
@@ -0,0 +1 @@
+In Wicket the concept of “model” is probably the most important topic of 
the entire framework and it is strictly related to the usage of its components. 
In addition, models are also an important element for  internationalization, as 
we will see in paragraph 12.6. However, despite their fundamental role, in 
Wicket models are not difficult to understand but the best way to learn how 
they work is to use them with forms. That's why we haven't talked about models 
so far, and why this chapter discusses these two topics together.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_1.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_1.gdoc 
b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_1.gdoc
new file mode 100644
index 0000000..ce458cc
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_1.gdoc
@@ -0,0 +1,68 @@
+
+
+Model is essentially a "facade":http://en.wikipedia.org/wiki/Facade_pattern 
interface which allows components to access and modify their data without 
knowing any detail about how they are managed or persisted. Every component has 
at most one related model, while a model can be shared among different 
components. In Wicket a model is any implementation of the interface 
@org.apache.wicket.model.IModel@:
+
+!uml-imodel.png!
+
+The IModel interface defines just the methods needed to get and set a data 
object (getObject() and setObject()), decoupling components from concrete 
details about the persistence strategy adopted for data. In addition, the level 
of indirection introduced by models allows access data object only when it is 
really needed (for example during the rendering phase) and not earlier when it 
may not be ready to be used.
+
+Any component can get/set its model as well as its data object using the 4 
public shortcut methods listed in the class diagram above. The two methods 
onModelChanged() and onModelChanging() are triggered by Wicket each time a 
model is modified: the first one is called after the model has been changed, 
the second one just before the change occurs. In the examples seen so far we 
have worked with Label component using its constructor which takes as input two 
string parameters, the component id and the text to display:
+
+{code}
+add(new Label("helloMessage", "Hello WicketWorld!"));
+{code}
+
+This constructor internally builds a model which wraps the second string 
parameter. That's why we didn't mention label model in the previous examples. 
Here is the code of this constructor:
+
+{code}
+public Label(final String id, String label) {
+       this(id, new Model<String>(label));
+}
+{code}
+
+Class @org.apache.wicket.model.Model@ is a basic implementation of @IModel@. 
It can wrap any object that implements the interface java.io.Serializable. The 
reason of this constraint over data object is that this model is stored in the 
web session, and we know from chapter 6 that data are stored into session using 
serialization.
+
+{note}
+In general, Wicket models support a detaching capability that allows us to 
work also with non-serializable objects as data model. We will see the 
detaching mechanism later in this chapter.
+{note}
+
+Just like any other Wicket components, Label provides a constructor that takes 
as input the component id and the model to use with the component. Using this 
constructor the previous example becomes:
+
+{code}
+add(new Label("helloMessage", new Model<String>("Hello WicketWorld!")));
+{code}
+
+{note}
+The Model class comes with a bunch of factory methods that makes it easier to 
build new model instances. For example the of(T object) method creates a new 
instance of Model which wraps any Object instance inside it. So instead of 
writing
+       
+       new Model<String>("Hello WicketWorld!")
+
+we can write
+       
+       Model.of("Hello WicketWorld!")
+
+If the data object is a List, a Map or a Set we can use similar methods called 
ofList, ofMap and ofSet.   
+From now on we will use these factory methods in our examples.
+{note}
+
+It's quite clear that if our Label must display a static text it doesn't make 
much sense to build a model by hand like we did in the last code example.
+However is not unusual to have a Label that must display a dynamic value, like 
the input provided by a user or a value read from a database. Wicket models are 
designed to solve these kinds of problems.
+
+Let's say we need a label to display the current time stamp each time a page 
is rendered. We can implement a custom model which returns a new Date instance 
when the getObject() method is called:
+
+{code}
+IModel timeStampModel = new Model<String>(){
+       @Override
+       public String getObject() {
+               return new Date().toString();
+       }
+};
+
+add(new Label("timeStamp", timeStampModel));
+{code}
+
+Even if sometimes writing a custom model could be a good choice to solve a 
specific problem, Wicket already provides a set of IModel implementations which 
should fit most of our needs. In the next paragraph we will see a couple of 
models that allow us to easily integrate JavaBeans with our web applications 
and in particular with our forms.
+
+{note}
+By default class Component escapes HTML sensitive characters (like '<', '>' or 
'&') from the textual representation of its model object. The term 'escape' 
means that these characters will be replaced with their corresponding HTML 
"entity":http://en.wikipedia.org/wiki/Character_entity_reference (for example 
'<' becomes '&lt; '). This is done for security reasons as a malicious user 
could attempt to inject markup or JavaScript into our pages. If we want to 
display the raw content stored inside a model, we can tell the Component class 
not to escape characters by calling the setEscapeModelStrings(false) method.
+{note}
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_2.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_2.gdoc 
b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_2.gdoc
new file mode 100644
index 0000000..b49ffcb
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_2.gdoc
@@ -0,0 +1,121 @@
+
+
+One of the main goals of Wicket is to use JavaBeans and POJO as data model, 
overcoming the impedance mismatch between web technologies and OO paradigm. In 
order to make this task as easy as possible, Wicket offers two special model 
classes: @org.apache.wicket.model.PropertyModel@ and 
@org.apache.wicket.model.CompoundPropertyModel@. We will see how to use them in 
the next two examples, using the following JavaBean as the data object:
+
+{code}
+public class Person implements Serializable {  
+       
+       private String name;
+       private String surname;
+       private String address;
+       private String email;
+       private String passportCode;
+       
+       private Person spouse;
+       private List<Person> children;
+       
+       public Person(String name, String surname) {
+               this.name = name;
+               this.surname = surname;
+       }
+
+       public String getFullName(){
+               return name + " " + surname;
+       } 
+
+       /*       
+        * Getters and setters for private fields
+     */
+}
+{code}
+
+h3. PropertyModel
+
+Let's say we want to display the name field of a Person instance with a label. 
We could, of course, use the Model class like we did in the previous example, 
obtaining something like this:
+
+{code}
+Person person = new Person();          
+//load person's data...
+               
+Label label = new Label("name", new Model(person.getName()));
+{code}
+
+However this solution has a huge drawback: the text displayed by the label 
will be static and if we change the value of the field, the label won't update 
its content. Instead, to always display the current value of a class field, we 
should use the @org.apache.wicket.model.PropertyModel@ model class:
+
+{code}
+Person person = new Person();          
+//load person's data...
+               
+Label label = new Label("name", new PropertyModel(person, "name"));
+{code}
+
+PropertyModel has just one constructor with two parameters: the model object 
(person in our example) and the name of the property we want to read/write 
("name" in our example). This last parameter is called property expression. 
Internally, methods getObject/setObject use property expression to get/set 
property's value. To resolve class properties PropertyModel uses class 
@org.apache.wicket.util.lang.Property@ Resolver which can access any kind of 
property, private fields included.
+
+Just like the Java language, property expressions support dotted notation to 
select sub properties. So if we want to display the name of the Person's spouse 
we can write:
+
+{code}
+Label label = new Label("spouseName", new PropertyModel(person, 
"spouse.name"));
+{code}
+
+{note}
+PropertyModel is null-safe, which means we don't have to worry if property 
expression includes a null value in its path. If such a value is encountered, 
an empty string will be returned.
+{note}
+
+If property is an array or a List, we can specify an index after its name. For 
example, to display the name of the first child of a Person we can write the 
following property expression:
+
+{code}
+Label label = new Label("firstChildName", new PropertyModel(person, 
"children.0.name"));
+{code}
+
+Indexes and map keys can be also specified using squared brackets: 
+
+{code}
+children[0].name ...
+mapField[key].subfield ...
+{code}
+
+h3. CompoundPropertyModel and model inheritance
+
+Class @org.apache.wicket.model.CompoundPropertyModel@ is a particular kind of 
model which is usually used in conjunction with another Wicket feature called 
model inheritance. With this feature, when a component needs to use a model but 
none has been assigned to it, it will search through the whole container 
hierarchy for a parent with an inheritable model. Inheritable models are those 
which implement interface @org.apache.wicket.model.IComponentInheritedModel@ 
and @CompoundPropertyModel@ is one of them. Once a @CompoundPropertyModel@ has 
been inherited by a component, it will behave just like a PropertyModel using 
the id of the component as property expression. As a consequence, to make the 
most of CompoundPropertyModel we must assign it to one of the containers of a 
given component, rather than directly to the component itself.
+
+For example if we use CompoundPropertyModel with the previous example (display 
spouse's name), the code would become like this:
+
+{code}
+//set CompoundPropertyModel as model for the container of the label
+setDefaultModel(new CompoundPropertyModel(person));
+
+Label label = new Label("spouse.name");        
+
+add(label);
+{code}
+
+Note that now the id of the label is equal to the property expression 
previously used with PropertyModel. Now as a further example let's say we want 
to extend the code above to display all of the main informations of a person 
(name, surname, address and email). All we have to do is to add one label for 
every additional information using the relative property expression as 
component id:
+
+{code}
+//Create a person named 'John Smith'
+Person person = new Person("John", "Smith");
+setDefaultModel(new CompoundPropertyModel(person));
+
+add(new Label("name"));
+add(new Label("surname"));
+add(new Label("address"));
+add(new Label("email"));
+add(new Label("spouse.name"));
+{code}
+
+CompoundPropertyModel can save us a lot of boring coding if we choose the id 
of components according to properties name. However it's also possible to use 
this type of model even if the id of a component does not correspond to a valid 
property expression. The method bind(String property) allows to create a 
property model from a given CompoundPropertyModel using the provided parameter 
as property expression. For example if we want to display the spouse's name in 
a label having "xyz" as id, we can write the following code:
+
+{code}
+//Create a person named 'John Smith'
+Person person = new Person("John", "Smith");
+CompoundPropertyModel compoundModel;
+setDefaultModel(compoundModel = new CompoundPropertyModel(person));
+
+add(new Label("xyz", compoundModel.bind("spouse.name")));
+{code}
+
+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 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

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_3.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_3.gdoc 
b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_3.gdoc
new file mode 100644
index 0000000..787f1ea
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_3.gdoc
@@ -0,0 +1,185 @@
+
+
+Web applications use HTML forms to collect user input and send it to the 
server. Wicket provides @org.apache.wicket.markup.html.form.Form@ class to 
handle web forms. This component must be bound to <form> tag. The following 
snippet shows how to create a very basic Wicket form in a page:
+
+Html:
+
+{code:html}
+<form wicket:id="form">
+    <input type="submit" value="submit"/>
+</form>
+{code}
+
+
+Java code:
+
+{code}
+Form form = new Form("form"){
+    @Override
+    protected void onSubmit() {
+       System.out.println("Form submitted.");
+    }
+};
+add(form);
+{code}
+
+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 
@org.apache.wicket.markup.html.form.IFormSubmitter@.
+
+h3. Form and models
+
+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:
+
+!uml-form-component.png!
+
+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.
+
+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 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}
+
+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.
+
+The following is a possible implementation of our form:
+
+{code}
+public class LoginForm extends Form {
+       
+       private TextField usernameField;
+       private PasswordTextField passwordField;
+       private Label loginStatus;
+               
+       public LoginForm(String id) {
+               super(id);
+                       
+               usernameField = new TextField("username", Model.of(""));
+               passwordField = new PasswordTextField("password", 
Model.of(""));                        
+               loginStatus = new Label("loginStatus", Model.of(""));
+                       
+               add(usernameField);
+               add(passwordField);
+               add(loginStatus);
+       }
+
+       public final void onSubmit() {
+               String username = (String)usernameField.getDefaultModelObject();
+               String password = (String)passwordField.getDefaultModelObject();
+
+               if(username.equals("test") && password.equals("test"))
+                       loginStatus.setDefaultModelObject("Congratulations!");
+               else
+                       loginStatus.setDefaultModelObject("Wrong username or 
password!");                       
+       }
+}
+{code}
+
+Inside form's constructor we build the three components used in the form and 
we assign them a model containing an empty string:
+
+{code}
+usernameField = new TextField("username", Model.of(""));
+passwordField = new PasswordTextField("password", Model.of(""));               
        
+loginStatus = new Label("loginStatus", Model.of(""));
+{code}
+
+If we don't provide a model to a form component, we will get the following 
exception on form submission:
+
+{code}
+java.lang.IllegalStateException: Attempt to set model object on null model of 
component: 
+{code}
+
+Component TextField corresponds to the standard text field, without any 
particular behavior or restriction on the allowed values. We must bind this 
component to the <input> tag with the attribute type set to "text". 
PasswordTextField is a subtype of TextFiled and it must be used with an <input> 
tag with the attribute type set to"password". For security reasons component 
PasswordTextField cleans its value at each request, so it wil be always empty 
after the form has been rendered. By default PasswordTextField fields are 
required, meaning that if we left them empty, the form won't be submitted (i.e. 
onSubmit won't be called). Class FormComponent provides method 
setRequired(boolean required) to change this behavior. Inside onSubmit, to 
get/set model objects we have used shortcut methods setDefaultModelObject and 
getDefaultModelObject. Both methods are defined in class Component (see class 
diagram from Illustration 9.1).
+
+The following are the possible markup and code for the login page:
+
+Html:
+
+{code:html}
+<html>
+       <head>
+               <title>Login page</title>
+       </head>
+       <body>
+               <form id="loginForm" method="get" wicket:id="loginForm">
+                       <fieldset>
+                       <legend style="color: #F90">Login</legend>
+                               <p wicket:id="loginStatus"></p>
+                               <span>Username: </span><input 
wicket:id="username" type="text" id="username" /><br/>
+                               <span>Password: </span><input 
wicket:id="password" type="password" id="password" />
+                               <p>
+                                       <input type="submit" name="Login" 
value="Login"/>
+                               </p>
+                   </fieldset>
+               </form>
+       </body>
+</html>
+{code}
+
+Java code:
+
+{code}
+public class HomePage extends WebPage {
+ 
+   public HomePage(final PageParameters parameters) {
+               
+               super(parameters);
+       add(new LoginForm("loginForm"));
+
+    }
+}
+{code}
+
+The example shows how Wicket form components can be used to store user input 
inside their model. However we can dramatically improve the form code using 
CompoundPropertyModel and its ability to access the properties of its model 
object. The revisited code is the following (the LoginFormRevisited project):
+
+{code}
+public class LoginForm extends Form{
+               
+               private String username;
+               private String password;
+               private String loginStatus;
+               
+               public LoginForm(String id) {
+                       super(id);                      
+                       setDefaultModel(new CompoundPropertyModel(this));
+                       
+                       add(new TextField("username"));
+                       add(new PasswordTextField("password"));
+                       add(new Label("loginStatus"));
+               }
+
+               public final void onSubmit() {                  
+                       if(username.equals("test") && password.equals("test"))
+                               loginStatus = "Congratulations!";
+                       else
+                               loginStatus = "Wrong username or password !";   
                
+               }
+       }
+{code}
+
+In this version the form itself is used as model object for its 
CompoundPropertyModel. This allows children components to have direct access to 
form fields and use them as backing objects, without explicitly creating a 
model for themselves.
+
+{note}
+Keep in mind that when CompoundPropertyModel is inherited, it does not 
consider the ids of traversed containers for the final property expression, but 
it will always use the id of the visited child. To understand this potential 
pitfall, let's consider the following initialization code of a page:
+
+{code}
+//Create a person named 'John Smith'
+Person person = new Person("John", "Smith");
+//Create a person named 'Jill Smith'
+Person spouse = new Person("Jill", "Smith");
+//Set Jill as John's spouse
+person.setSpouse(spouse);
+
+setDefaultModel(new CompoundPropertyModel(person));
+WebMarkupContainer spouse = new WebMarkupContainer("spouse");
+Label name;
+spouse.add(name = new Label("name"));
+
+add(spouse);
+{code}
+
+The value displayed by label "name" will be "John" and not the spouse's name  
"Jill" as you may expect. In this example the label doesn't own a model, so it 
must search up its container hierarchy for an inheritable model. However, its 
container (WebMarkup Container with id 'spouse') doesn't own a model, hence the 
request for a model is forwarded to the parent container, which in this case is 
the page. In the end the label inherits CompoundPropertyModel from page but 
only its own id is used for the property expression. The containers in between 
are never taken into account for the final property expression.
+{note}
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_4.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_4.gdoc 
b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_4.gdoc
new file mode 100644
index 0000000..d79b218
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_4.gdoc
@@ -0,0 +1,54 @@
+
+
+Class @org.apache.wicket.markup.html.form.DropDownChoice@ is the form 
component needed to display a list of possible options as a drop-down list 
where users can select one of the proposed options. This component must be used 
with <select> tag:
+
+Html:
+
+{code:html}
+<form wicket:id="form">
+       Select a fruit: <select wicket:id="fruits"></select>
+<div><input type="submit" value="submit"/></div>
+</form>
+{code}
+
+Java code:
+
+{code}
+List<String> fruits = Arrays.asList("apple", "strawberry", "watermelon"); 
+form.add(new DropDownChoice<String>("fruits", new Model(), fruits));
+{code}
+
+Screenshot of generated page:
+
+!dropdown-choice.png!
+
+In addition to the component id, in order to build a DropDownChoice we need to 
provide to its constructor two further parameters:
+
+* a model containing the current selected item. This parameter is not required 
if we are going to inherit a CompoundPropertyModel for this component.
+* a list of options to display which can be supplied as a model or as a 
regular java.util.List.
+
+In the example above the possible options are provided as a list of String 
objects. Now let's take a look at the markup generated for them:
+
+{code:html}
+<select name="fruits" wicket:id="fruits">
+       <option value="" selected="selected">Choose One</option>
+       <option value="0">apple</option>
+       <option value="1">strawberry</option>
+       <option value="2">watermelon</option>
+</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 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@ inte
 rface. 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: 
+
+Java code:
+
+{code}
+List<Person> persons; 
+//Initialize the list of persons here...
+ChoiceRenderer personRenderer = new ChoiceRenderer("fullName", "passportCode");
+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

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_5.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_5.gdoc 
b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_5.gdoc
new file mode 100644
index 0000000..a194524
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_5.gdoc
@@ -0,0 +1,101 @@
+
+
+Models that implement the interface @org.apache.wicket.model.IChainingModel@ 
can be used to build a chain of models. These kinds of models are able to 
recognize whether their model object is itself an implementation of IModel and 
if so, they will call getObject on the wrapped model and the returned value 
will be the actual model object. In this way we can combine the action of an 
arbitrary number of models, making exactly a chain of models. Chaining models 
allows to combine different data persistence strategies, similarly to what we 
do with chains of "I/O 
streams.":http://java.sun.com/developer/technicalArticles/Streams/ProgIOStreams 
To see model chaining in action we will build a page that implements the 
List/Detail View pattern, where we have a drop-down list of Person objects and 
a form to display and edit the data of the current selected Person.
+
+The example page will look like this:
+
+!model-chaining.png!
+
+What we want to do in this example is to chain the model of the DropDownChoice 
(which contains the selected Person) with the model of the Form. In this way 
the Form will work with the selected Person as backing object. The 
DropDownChoice component can be configured to automatically update its model 
each time we change the selected item on the client side. All we have to do is 
to override method wantOnSelectionChangedNotifications to make it return true. 
In practice, when this method returns true, DropDownChoice will submit its 
value every time JavaScript event onChange occurs, and its model will be 
consequently updated. To leverage this functionality, DropDownChoice doesn't 
need to be inside a form.
+
+The following is the resulting markup of the example page:
+
+{code:html}
+...
+<body>
+       List of persons <select wicket:id="persons"></select> <br/>
+       <br/>
+       <form wicket:id="form">         
+               <div style="display: table;">
+                       <div style="display: table-row;">
+                               <div style="display: table-cell;">Name: </div>
+                               <div style="display: table-cell;">
+                                       <input type="text" wicket:id="name"/> 
+                               </div>  
+                       </div>
+                       <div style="display: table-row;">
+                               <div style="display: table-cell;">Surname: 
</div>
+                               <div style="display: table-cell;">
+                                                                       <input 
type="text" wicket:id="surname"/>
+                                                               </div>  
+                                                       </div>
+                                                       <div style="display: 
table-row;">
+                                                               <div 
style="display: table-cell;">Address: </div>
+                                                               <div 
style="display: table-cell;">
+                                                                       <input 
type="text" wicket:id="address"/>
+                                                               </div>  
+                                                       </div>
+                                                       <div style="display: 
table-row;">
+                                                               <div 
style="display: table-cell;">Email: </div>
+                                                               <div 
style="display: table-cell;">
+                                                                       <input 
type="text" wicket:id="email"/>
+                                                               </div>
+                                                       </div>
+                                               </div>  
+                                               <input type="submit" 
value="Save"/>
+                                       </form>
+                               </body>                         
+{code}
+
+The initialization code for DropDownChoice is the following:
+
+{code}
+Model<Person> listModel = new Model<Person>();
+ChoiceRenderer<Person> personRender = new ChoiceRenderer<Person>("fullName");
+personsList = new DropDownChoice<Person>("persons", listModel, loadPersons(), 
personRender){
+               
+               @Override
+               protected boolean wantOnSelectionChangedNotifications() {
+                       return true;
+               }
+               
+};
+{code}
+
+As choice render we have used the basic implementation provided with the 
org.apache.wicket .markup.html.form.ChoiceRenderer class that we have seen in 
the previous paragraph. loadPersons() is just an utility method which generates 
a list of Person instances. The model for DropDownChoice is a simple instance 
of the Model class.
+
+Here is the whole code of the page (except for the loadPersons() method):
+
+{code}
+public class PersonListDetails extends WebPage {
+  private Form form;
+  private DropDownChoice<Person> personsList;
+  
+  public PersonListDetails(){
+    Model<Person> listModel = new Model<Person>();
+    ChoiceRenderer<Person> personRender = new 
ChoiceRenderer<Person>("fullName");
+    
+    personsList = new DropDownChoice<Person>("persons", listModel, 
loadPersons(),
+                                                         personRender){
+      @Override
+      protected boolean wantOnSelectionChangedNotifications() {
+        return true;
+      }
+           };    
+
+           add(personsList);
+
+           form = new Form("form", new 
CompoundPropertyModel<Person>(listModel));    
+           form.add(new TextField("name"));
+           form.add(new TextField("surname"));
+           form.add(new TextField("address"));
+           form.add(new TextField("email"));
+
+           add(form);
+         }
+              //loadPersons()
+              //...
+       }
+{code}
+
+The two models work together as a pipeline where the output of method 
getObject of Model is the model object of CompoundPropertyModel. As we have 
seen, model chaining allows us to combine the actions of two or more models 
without creating new custom implementations.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_6.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_6.gdoc 
b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_6.gdoc
new file mode 100644
index 0000000..2a9a097
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_6.gdoc
@@ -0,0 +1,82 @@
+
+
+In chapter 6 we have seen how Wicket uses serialization to store page 
instances. When an object is serialized, all its referenced objects are 
recursively serialized. For a page this means that all its children components, 
their related models as well as the model objects inside them will be 
serialized. 
+For model objects this could be a serious issue for (at least) two main 
reasons:
+
+# The model object could be a very large instance, hence serialization would 
become very expensive in terms of time and memory.
+# We simply may not be able to use a serializable object as model object. In 
paragraphs 1.4 and 9.2 we stated that Wicket allows us to use a POJO as backing 
object, but 
"POJOs":http://en.wikipedia.org/wiki/Plain_Old_Java_Object#Definition are 
ordinary objects with no prespecified interface, annotation or superclass, 
hence they are not required to implement the standard Serializable interface.
+
+To cope with these problems IModel extends another interface called 
IDetachable.
+
+!detachable-models.png!
+
+This interface provides a method called detach() which is invoked by Wicket at 
the end of web request processing when data model is no more needed but before 
serialization occurs. Overriding this method we can clean any reference to data 
object keeping just the information needed to retrieve it later (for example 
the id of the table row where our data are stored). In this way we can avoid 
the serialization of the object wrapped into the model overcoming both the 
problem with non-serializable objects and the one with large data objects.
+
+Since IModel inherits from IDetachable, every model of Wicket is 
“detachable”, although not all of them implement a detaching policy (like 
the Model class). 
+Usually detaching operations are strictly dependent on the persistence 
technology adopted for model objects (like a relational db, a NoSQL db, a 
queue, etc), so it's not unusual to write a custom detachable model suited for 
the persistence technology chosen for a given project. To ease this task Wicket 
provides abstract model LoadableDetachableModel. This class internally holds a 
transient reference to a model object which is initialized the first time 
getObject()is called to precess a request. The concrete data loading is 
delegated to abstract method T load(). The reference to a model object is 
automatically set to null at the end of the request by the detach() method.
+
+The following class diagram summarizes the methods defined inside 
LoadableDetachableModel.
+
+!loadable-detachable-model.png!
+
+onDetach and onAttach can be overridden in order to obtain further control 
over the detaching procedure.
+
+Now as example of a possible use of LoadableDetachableModel, we will build a 
model designed to work with entities managed via 
"JPA.":http://en.wikipedia.org/wiki/Java_Persistence_API To understand the 
following code a basic knowledge of JPA is required even if we won't go into 
the detail of this standard.
+
+{warning}
+The following model is provided for example purposes only and is not intended 
to be used in production environment. Important aspects such as transaction 
management are not taken into account and you should rework the code before 
considering to use it.
+{warning}
+
+{code}
+public class JpaLoadableModel<T> extends LoadableDetachableModel<T> {
+  
+  private EntityManagerFactory entityManagerFactory;
+  private Class<T> entityClass;
+  private Serializable identifier;
+  private List<Object> constructorParams;
+  
+  public JpaLoadableModel(EntityManagerFactory entityManagerFactory, T entity) 
{
+     
+       super();
+     
+       PersistenceUnitUtil util = 
entityManagerFactory.getPersistenceUnitUtil();
+             
+               this.entityManagerFactory = entityManagerFactory;
+           this.entityClass = (Class<T>) entity.getClass();
+           this.identifier = (Serializable) util.getIdentifier(entity);
+
+           setObject(entity);
+       }
+
+       @Override
+       protected T load() {
+          T entity = null;
+
+          if(identifier != null) {  
+              EntityManager entityManager = 
entityManagerFactory.createEntityManager();
+              entity = entityManager.find(entityClass, identifier);
+            }
+            return entity;
+          }
+
+       @Override
+       protected void onDetach() {
+          super.onDetach();
+
+            T entity = getObject();
+            PersistenceUnitUtil persistenceUtil = 
entityManagerFactory.getPersistenceUnitUtil();
+
+            if(entity == null) return;
+
+            identifier = (Serializable) persistenceUtil.getIdentifier(entity); 
   
+         }
+       }
+{code}
+
+The constructor of the model takes as input two parameters: an implementation 
of the JPA interface  javax.persistence.EntityManagerFactory to manage JPA 
entities and the entity that must be handled by this model. Inside its 
constructor the model saves the class of the entity and its id (which could be 
null if the entity has not been persisted yet). These two informations are 
required to retrieve the entity at a later time and are used by the load method.
+
+onDetach is responsible for updating the entity id before detachment occurs. 
The id can change the first time an entity is persisted (JPA generates a new id 
and assigns it to the entity). Please note that this model is not responsible 
for saving any changes occurred to the entity object before it is detached. If 
we don't want to loose these changes we must explicitly persist the entity 
before the detaching phase occurs.
+
+{warning}
+Since the model of this example holds a reference to the EntityManager 
Factory, the implementation in use must be serializable.
+{warning}
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_7.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_7.gdoc 
b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_7.gdoc
new file mode 100644
index 0000000..a34b7f5
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_7.gdoc
@@ -0,0 +1,30 @@
+
+
+Sometimes our custom components may need to use more than a single model to 
work properly. In such a case we must manually detach the additional models 
used by our components. In order to do this we can overwrite the Component's 
onDetach method that is called at the end of the current request. The following 
is the generic code of a component that uses two models:
+
+{code}
+/**
+ * 
+ * fooModel is used as main model while beeModel must be manually detached
+ *
+ */
+public class ComponetTwoModels extends Component{
+
+       private IModel<Bee> beeModel;
+
+       public ComponetTwoModels(String id, IModel<Foo> fooModel, IModel<Bee> 
beeModel) {
+               super(id, fooModel);
+               this.beeModel = beeModel;
+       }
+
+       @Override
+       public void onDetach() {
+               if(beeModel != null)
+          beeModel.detach();
+             
+              super.onDetach();
+       }
+}
+{code}
+
+When we overwrite onDetach we must call the super class implementation of this 
method, usually as last line in our custom implementation.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_8.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_8.gdoc 
b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_8.gdoc
new file mode 100644
index 0000000..e19ac44
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_8.gdoc
@@ -0,0 +1,22 @@
+
+
+Like many people new to Wicket, you may need a little time to fully understand 
the power and the advantages of using models. Taking your first steps with 
Wicket you may be tempted to pass row objects to your components instead of 
using models:
+
+{code}
+/**
+ * 
+ * NOT TO DO: passing row objects to components instead of using models!
+ *
+ */
+public class CustomComponent extends Component{
+       private FooBean fooBean;
+
+       public CustomComponent(String id, FooBean fooBean) {
+               super(id);
+               this.fooBean = fooBean;
+       }
+       //...some other ugly code :)...
+}
+{code}
+
+That's a bad practice and you must avoid it. Using models we do not only 
decouple our components from the data source, but we can also relay on them (if 
they are dynamic) to work with the most up-to-date version of our model object. 
If we decide to bypass models we lose all these advantages and we force model 
objects to be serialized.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_9.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_9.gdoc 
b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_9.gdoc
new file mode 100644
index 0000000..95f3d97
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/modelsforms/modelsforms_9.gdoc
@@ -0,0 +1,4 @@
+
+
+Models are at the core of Wicket and they are the basic ingredient needed to 
taste the real power of the framework. In this chapter we have seen how to use 
models to bring data to our components without littering their code with 
technical details about their persistence strategy.
+We have also introduced Wicket forms as complementary topic. With forms and 
models we are able to bring our applications to life allowing them to interact 
with users. But what we have seen in this chapter about Wicket forms is just 
the tip of the iceberg. That's why the next chapter is entirely dedicated to 
them.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/nativewebsockets.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/nativewebsockets.gdoc 
b/wicket-user-guide/src/docs/guide/nativewebsockets.gdoc
new file mode 100644
index 0000000..514f3db
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/nativewebsockets.gdoc
@@ -0,0 +1,10 @@
+[WebSockets|http://en.wikipedia.org/wiki/WebSocket] is a technology that 
provides full-duplex communications channels over a single TCP connection.
+This means that once the browser establish a web socket connection to the 
server the server can push data back to the browser without the browser 
explicitly asking again and again whether there is something new for it.
+
+Wicket Native WebSockets modules provide functionality to integrate with the 
non-standard APIs provided by different web containers (like [Apache 
Tomcat|http://tomcat.apache.org/] and [Jetty|http://www.eclipse.org/jetty/]) 
and standard [JSR356|https://www.jcp.org/en/jsr/detail?id=356] implementations.
+
+{warning}
+Native WebSocket works only when both the browser and the web containers 
support WebSocket technology. There are no plans to add support to fallback to 
long-polling, streaming or any other technology that simulates two way 
communication. Use it only if you really know that you will run your 
application in an environment that supports WebSockets.
+Currently supported web containers are Jetty 7.5+ , Tomcat 7.0.27+ and JBoss 
WildFly 8.0.0+.
+Supported browsers can be found at 
[caniuse.com|http://caniuse.com/#search=websocket].
+{warning}

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_1.gdoc
----------------------------------------------------------------------
diff --git 
a/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_1.gdoc 
b/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_1.gdoc
new file mode 100644
index 0000000..8a3b4fc
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_1.gdoc
@@ -0,0 +1,7 @@
+Each of the modules provide a specialization of 
@org.apache.wicket.protocol.http.WicketFilter@ that registers implementation 
specific endpoint when an HTTP request is 
[upgraded|http://en.wikipedia.org/wiki/WebSocket#WebSocket_protocol_handshake] 
to WebSocket one. Later Wicket uses this endpoint to write data back to the 
browser and read data sent by it. 
+
+WebSockets communication can be used in a Wicket page by using 
@org.apache.wicket.protocol.ws.api.WebSocketBehavior@ or in a IResource by 
exteding @org.apache.wicket.protocol.ws.api.WebSocketResource@.
+When a client is connected it is being registered in a application scoped 
registry using as a key the application name, the client http session id, and 
the id of the page or the resource name that registered it. Later when the 
server needs to push a message it can use this registry to filter out which 
clients need to receive the message.
+
+When a message is received from the client Wicket wraps it in 
@IWebSocketMessage@ and calls WebSocketBehavior#*onMessage()* or 
WebSocketResource#*onMessage()* where the application logic can react on it.
+The server can push plain text and binary data to the client, but it can also 
add components for re-render, prepend/append JavaScript as it can do with 
[Ajax|guide:ajax].

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_2.gdoc
----------------------------------------------------------------------
diff --git 
a/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_2.gdoc 
b/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_2.gdoc
new file mode 100644
index 0000000..5af9914
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_2.gdoc
@@ -0,0 +1,125 @@
+* *Classpath dependency*
+
+Depending on the web container that is used the application has to add a 
dependency to either:
+
+- for Jetty 9.0.x
+{code}
+<dependency>
+  <groupId>org.apache.wicket</groupId>
+  <artifactId>wicket-native-websocket-jetty9</artifactId>
+  <version>...</version>
+</dependency>
+{code}
+
+- for Jetty 7.x and 8.x
+{code}
+<dependency>
+  <groupId>org.apache.wicket</groupId>
+  <artifactId>wicket-native-websocket-jetty</artifactId>
+  <version>...</version>
+</dependency>
+{code}
+
+- for Tomcat 7.0.27+ (the old, non-JSR356 implementation)
+{code}
+<dependency>
+  <groupId>org.apache.wicket</groupId>
+  <artifactId>wicket-native-websocket-tomcat</artifactId>
+  <version>...</version>
+</dependency>
+{code}
+
+- for JSR356 complaint implementations (at the moment are supported: Tomcat 
8.0+, Tomcat 7.0.47+, Jetty 9.1.0+ and JBoss Wildfly 8.0.0+)
+{code}
+<dependency>
+  <groupId>org.apache.wicket</groupId>
+  <artifactId>wicket-native-websocket-javax</artifactId>
+  <version>...</version>
+</dependency>
+{code}
+
+{note}
+All web containers providing JSR356 implementation are built with Java 7. This 
is the reason why @wicket-native-websocket-javax@ module is available only with 
Wicket 7.x. If your application runs with JRE 7.x then you can
+use @wicket-native-websocket-javax@ together with the latest version of Wicket 
6.x. Beware that the API/implementation of @wicket-native-websocket-javax@ may 
change before Wicket 7.0.0 is released!
+{note}
+
+{note}
+The examples above show snippets for Maven's pom.xml but the application can 
use any other dependency management tool like [Gradle|http://www.gradle.org/], 
[SBT|http://www.scala-sbt.org/], ...
+{note}
+
+* *web.xml*
+
+In @WEB-INF/web.xml@ replace the usage of *WicketFilter* with any of the 
following depending on the web container that is used:
+
+For Jetty 9.0.x:
+{code}
+<filter-class>org.apache.wicket.protocol.ws.jetty9.Jetty9WebSocketFilter</filter-class>
+{code}
+
+For Jetty 7.5+ and 8.x:
+{code}
+<filter-class>org.apache.wicket.protocol.ws.jetty7.Jetty7WebSocketFilter</filter-class>
+{code}
+
+For Tomcat 7.0.27+ (old implementation):
+{code}
+<filter-class>org.apache.wicket.protocol.ws.tomcat7.Tomcat7WebSocketFilter</filter-class>
+{code}
+
+For JSR356 complaint web containers (at the moment: Tomcat 7.0.47+, Tomcat 8.x 
and Jetty 9.1.x):
+{code}
+<filter-class>org.apache.wicket.protocol.ws.javax.JavaxWebSocketFilter</filter-class>
+{code}
+
+
+
+* *WebSocketBehavior*
+
[email protected]@ is similar to Wicket 
Ajax behaviors that you may have used.
+Add WebSocketBehavior to the page (or to any component in the page) that will 
use web socket communication:
+
+{code}
+public class MyPage extends WebPage {
+ 
+  public MyPage()
+  {
+    add(new WebSocketBehavior() {
+      @Override
+      protected void onMessage(WebSocketRequestHandler handler, TextMessage 
message)
+      {
+        String msg = message.getText();
+        // do something with msg
+      }
+    });
+  }
+}
+{code}
+
+Use @message.getText()@ to read the message sent by the client and use 
@handler.push(String)@ to push a text message to the connected client. 
Additionally you can use @handler.add(Component...)@ to add Wicket components 
for re-render, @handler#prependJavaScript(CharSequence)@ and 
@handler#appendJavaScript(CharSequence)@ as you do with @AjaxRequestTarget@.
+
+* *WebSocketResource*
+
+Wicket allows one thread at a time to use a page instance to simplify the 
usage of the pages in multithreaded enviroment. When a WebSocket message is 
sent to a page Wicket needs to acquire the lock to that page to be able to pass 
the @IWebSocketMessage@ to the @WebSocketBehavior@. This may be problematic 
when the application needs to send many messages from the client to the server.
+For this reason Wicket provides @WebSocketResource@ - an IResource 
implemetation that provides the same APIs as @WebSocketBehavior@. The benefit 
is that there is no need of synchronization as with the pages and the drawback 
is that @WebSocketRequesthandler#add(Component...)@ method cannot be used 
because there is no access to the components in an @IResource@.
+
+To register such WebSocket resource add such line to @YourApplication#init()@ 
method:
+{code}
+getSharedResources().add("someName", new MyWebSocketResource());
+{code}
+
+and 
+{code}
+  page.add(new BaseWebSocketBehavior("someName"));
+{code}
+to any page. This will prepare the JavaScript connection for you.
+
+* *WebSocket connection registry*
+
+To push data to one or more clients the application can use the 
@IWebSocketConnectionRegistry@ to find all registered connections and send data 
to all/any of them:
+
+{code}
+Application application = Application.get(applicationName);
+WebSocketSettings webSocketSettings = 
WebSocketSettings.Holder.get(application);
+IWebSocketConnectionRegistry webSocketConnectionRegistry = 
webSocketSettings.getConnectionRegistry();
+IWebSocketConnection connection = 
webSocketConnectionRegistry.getConnection(application, sessionId, key);
+{code}
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_3.gdoc
----------------------------------------------------------------------
diff --git 
a/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_3.gdoc 
b/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_3.gdoc
new file mode 100644
index 0000000..87588f1
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_3.gdoc
@@ -0,0 +1,40 @@
+By adding a @(Base)WebSocketBehavior@ to your component(s) Wicket will 
contribute @wicket-websocket-jquery.js@ library which provides some helper 
functions to write your client side code. There is a default websocket 
connection per Wicket Page opened for you which you can use like:
+{code}
+Wicket.WebSocket.send('{msg: "my message"}').
+{code}
+
+If you need more WebSocket connections then you can do: 
+{code}
+var ws = new Wicket.WebSocket(); 
+ws.send('message');
+{code}
+
+To close a connection: 
+{code}
+Wicket.WebSocket.close()
+{code}
+
+or 
+{code}
+ws.close()
+{code}
+
+Wicket.WebSocket is a simple wrapper around the native window.WebSocket API 
which is used to intercept the calls and to fire special JavaScript events 
(Wicket.Event PubSub).
+Once a page that contributes @(Base)WebSocketBehavior@ is rendered the client 
may react on messages pushed by the server by subscribing to the 
@'/websocket/message'@ event:
+
+{code}
+Wicket.Event.subscribe("/websocket/message", function(jqEvent, message) {
+  var data = JSON.parse(message);
+  processData(data); // does something with the pushed message
+});
+{code}
+
+Here is a table of all events that the application can subscribe to:
+{table}
+Event name | Arguments | Description
+/websocket/open | jqEvent | A WebSocket connection has been just opened
+/websocket/message | jqEvent, message | A message has been received from the 
server
+/websocket/closed | jqEvent | A WebSocket connection has been closed
+/websocket/error | jqEvent | An error occurred in the communication. The 
connection will be closed
+{table}
+

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_4.gdoc
----------------------------------------------------------------------
diff --git 
a/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_4.gdoc 
b/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_4.gdoc
new file mode 100644
index 0000000..98ba074
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_4.gdoc
@@ -0,0 +1,2 @@
+The module provides 
@org.apache.wicket.protocol.ws.util.tester.WebSocketTester@ which gives you the 
possibility to emulate sending and receiving messages without the need to run 
in a real web container, as WicketTester does this for HTTP requests.
+Check 
[WebSocketTesterBehaviorTest|https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/test/java/org/apache/wicket/protocol/ws/util/tester/WebSocketTesterBehaviorTest.java?source=c]
  and 
[WebSocketTesterResourceTest|https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/test/java/org/apache/wicket/protocol/ws/util/tester/WebSocketTesterResourceTest.java]
 for examples.

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_5.gdoc
----------------------------------------------------------------------
diff --git 
a/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_5.gdoc 
b/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_5.gdoc
new file mode 100644
index 0000000..52c1568
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_5.gdoc
@@ -0,0 +1 @@
+Wicket-Atmosphere experimental module provides integration with 
[Atmosphere|https://github.com/Atmosphere/atmosphere] and let it handle the 
inconsistencies in WebSocket protocol support in different browsers and web 
containers. If either the browser or the web container do not support 
WebSockets then Atmosphere will downgrade (depending on the configuration) to 
either long-polling, streaming, server-side events, jsonp, ... to simulate the 
long running connection.

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_6.gdoc
----------------------------------------------------------------------
diff --git 
a/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_6.gdoc 
b/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_6.gdoc
new file mode 100644
index 0000000..605c4ec
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/nativewebsockets/nativewebsockets_6.gdoc
@@ -0,0 +1,2 @@
+# Request and session scoped beans do not work.
+The Web Socket communication is not processed by Servlet Filters and Listeners 
and thus the Dependency Injection libraries have no chance to export the 
request and session bean proxies.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/redirects.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/redirects.gdoc 
b/wicket-user-guide/src/docs/guide/redirects.gdoc
new file mode 100644
index 0000000..1442f7a
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/redirects.gdoc
@@ -0,0 +1,75 @@
+Quite a few teams have already got stuck into the following problem when 
working with wicket forms in a clustered environment while having 2 (or more) 
tomcat server with enabled session replication running.
+
+In case of invalid data being submitted with a form instance for example, it 
seemed like according error messages wouldn’t be presented when the same form 
page gets displayed again. Sometimes! And sometimes they would! One of those 
nightmares of rather deterministic programmer’s life. This so called Lost In 
Redirection problem, even if it looks like a wicket bug at first, is rather a 
result of a default setting in wicket regarding the processing of form 
submissions in general. In order to prevent another wide known problem of 
double form submissions, Wicket uses a so called REDIRECT_TO_BUFFER strategy 
for dealing with rendering a page after web form’s processing (@see 
IRequestCycleSettings#RenderStrategy).
+
+What does the default RenderStrategy actually do?
+
+Both logical parts of a single HTTP request, an action and a render part get 
processed within the same request, but instead of streaming the render result 
to the browser directly, the result is cached on the server first.
+
+!lost-in-redirection-mockup.png!
+
+Wicket will create an according BufferedHttpServletResponse instance that will 
be used to cache the resulting HttpServletResponse within the WebApplication.
+
+!lost-in-redirection-mockup2.png!
+
+After the buffered response is cached the HTTP status code of 302 get’s 
provided back to the browser resulting in an additional GET request to the 
redirect URL (which Wicket sets to the URL of the Form itself). There is a 
special handling code for this case in the WicketFilter instance that then 
looks up a Map of buffered responses within the WebApplication accordingly. If 
an appropriate already cached response for the current request is found, it 
get’s streamed back to the browser immediately. No additional form processing 
happens now. The following is a code snippet taken from WicketFilter:
+
+{code}
+// Are we using REDIRECT_TO_BUFFER?
+if (webApplication.getRequestCycleSettings().getRenderStrategy() == 
IRequestCycleSettings.REDIRECT_TO_BUFFER)
+{
+    // Try to see if there is a redirect stored
+    // try get an existing session
+    ISessionStore sessionStore = webApplication.getSessionStore();
+    String sessionId = sessionStore.getSessionId(request, false);
+    if (sessionId != null)
+    {
+        BufferedHttpServletResponse bufferedResponse = null;
+        String queryString = servletRequest.getQueryString();
+        // look for buffered response
+        if (!Strings.isEmpty(queryString))
+        {
+            bufferedResponse = webApplication.popBufferedResponse(sessionId,
+                queryString);
+        }
+        else
+        {
+            bufferedResponse = webApplication.popBufferedResponse(sessionId,
+                relativePath);
+        }
+        // if a buffered response was found
+        if (bufferedResponse != null)
+        {
+            bufferedResponse.writeTo(servletResponse);
+            // redirect responses are ignored for the request
+            // logger...
+            return true;
+        }
+    }
+}
+{code}
+
+So what happens in case you have 2 server running your application with 
session replication and load balancing turned on while using the default 
RenderStrategy described above?
+
+Since a Map of buffered responses is cached within a WebApplication instance 
that does not get replicated between the nodes obviously, a redirect request 
that is suppose to pick up the previously cached response (having possibly form 
violation messages inside) potentially get’s directed to the second node in 
your cluster by the load balancer. The second node does not have any responses 
already prepared and cached for your user. The node therefore handles the 
request as a completely new request for the same form page and displays a fresh 
new form page instance to the user accordingly.
+
+!lost-in-redirection-mockup3.png!
+
+Unfortunately, there is currently no ideal solution to the problem described 
above. The default RenderStrategy used by Apache Wicket simply does not work 
well in a fully clustered environment with load balancing and session 
replication turned on. One possibility is to change the default render strategy 
for your application to a so called ONE_PASS_RENDER RenderStrategy which is the 
more suitable option to use when you want to do sophisticated (non-sticky 
session) clustering. This is easily done in the init method of your own 
subclass of Wicket’s WebApplication :
+
+{code}
+@Override
+protected void init() {
+    getRequestCycleSettings().setRenderStrategy(
+        IRequestCycleSettings.ONE_PASS_RENDER);
+}
+{code}
+
+ONE_PASS_RENDER RenderStrategy does not solve the double submit problem 
though! So this way you’d only be trading one problem for another one 
actually.
+
+You could of course turn on the session stickiness between your load balancer 
(apache server) and your tomcat server additionally to the session replication 
which would be the preferred solution in my opinion.
+
+!lost-in-redirection-mockup4.png!
+
+Session replication would still provide you with failover in case one of the 
tomcat server dies for whatever reason and sticky sessions would ensure that 
the Lost In Redirection problem does not occur any more.
+

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/repeaters.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/repeaters.gdoc 
b/wicket-user-guide/src/docs/guide/repeaters.gdoc
new file mode 100644
index 0000000..21e6c3a
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/repeaters.gdoc
@@ -0,0 +1,22 @@
+A common task for web applications is to display a set of items. The most 
typical scenario where we need such kind of visualization is when we have to 
display some kind of search result. With the old template-based technologies 
(like JSP) we used to accomplish this task using classic for or while loops:
+
+{code:html}
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<title>Insert title here</title>
+</head>
+<body>
+  <%
+    for(int i = 12; i<=32; i++) {
+      %>
+      <div>Hello! I'm index n°<%= %></div>
+  <% 
+    }
+  %>
+</body>
+{code}
+
+To ease this task Wicket provides a number of special-purpose components 
called repeaters which are designed to use their related markup to display the 
items of a given set in a more natural and less chaotic way.
+
+In this chapter we will see some of the built-in repeaters that come with 
Wicket.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/repeaters/repeaters_1.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/repeaters/repeaters_1.gdoc 
b/wicket-user-guide/src/docs/guide/repeaters/repeaters_1.gdoc
new file mode 100644
index 0000000..7f636a8
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/repeaters/repeaters_1.gdoc
@@ -0,0 +1,30 @@
+
+
+Component @org.apache.wicket.markup.repeater.RepeatingView@ is a container 
which renders its children components using the tag it is bound to. It can 
contain an arbitrary number of children elements and we can obtain a new valid 
id for a new child calling its method newChildId(). This component is 
particularly suited when we have to repeat a simple markup fragment, for 
example when we want to display some items as a HTML list:
+
+*HTML:*
+{code:html}
+<ul>
+    <li wicket:id="listItems"></li>
+</ul>
+{code}
+
+*Java Code:*
+{code}
+RepeatingView listItems = new RepeatingView("listItems");
+
+listItems.add(new Label(listItems.newChildId(), "green"));
+listItems.add(new Label(listItems.newChildId(), "blue"));
+listItems.add(new Label(listItems.newChildId(), "red"));
+{code}
+
+*Generated markup:*
+{code:html}
+<ul>
+    <li>green</li>
+    <li>blue</li>
+    <li>red</li>
+</ul>
+{code}
+
+As we can see in this example, each child component has been rendered using 
the parent markup as if it was its own.

http://git-wip-us.apache.org/repos/asf/wicket/blob/93dca376/wicket-user-guide/src/docs/guide/repeaters/repeaters_2.gdoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/docs/guide/repeaters/repeaters_2.gdoc 
b/wicket-user-guide/src/docs/guide/repeaters/repeaters_2.gdoc
new file mode 100644
index 0000000..6b06ea8
--- /dev/null
+++ b/wicket-user-guide/src/docs/guide/repeaters/repeaters_2.gdoc
@@ -0,0 +1,48 @@
+
+
+As its name suggests, component @org.apache.wicket.markup.html.list.ListView@ 
is designed to display a given list of objects which can be provided as a 
standard Java List or as a model containing the concrete List. ListView 
iterates over the list and creates a child component of type 
@org.apache.wicket.markup.html.list.ListItem@ for every encountered item. 
+
+Unlike RepeatingView this component is intended to be used with complex markup 
fragments containing nested components. 
+
+To generate its children, ListView calls its abstract method 
populateItem(ListItem<T> item) for each item in the list, so we must provide an 
implementation of this method to tell the component how to create its children 
components. In the following example we use a ListView to display a list of 
Person objects:
+
+*HTML:*
+{code:html}
+...
+       <body>
+               <div id="bd" style="display: table;">
+                       <div wicket:id="persons" style="display: table-row;">
+                               <div style="display: table-cell;"><b>Full name: 
</b></div>
+                               <div wicket:id="fullName" style="display: 
table-cell;"></div>
+                       </div>
+               </div>
+       </body>
+...
+{code}
+
+*Java Code (Page Constructor):*
+{code}
+public HomePage(final PageParameters parameters) {
+          List<Person> persons = Arrays.asList(new Person("John", "Smith"), 
+                                        new Person("Dan", "Wong"));
+               
+   add(new ListView<Person>("persons", persons) {
+       @Override
+       protected void populateItem(ListItem<Person> item) {
+          item.add(new Label("fullName", new PropertyModel(item.getModel(), 
"fullName")));
+       }                       
+   });
+}
+{code}
+
+*Screenshot of generated page:*
+
+!simple-listview-screenshot.png!
+
+In this example we have displayed the full name of two Person's instances. The 
most interesting part of the code is the implementation of method populateItem 
where parameter item is the current child component created by ListView and its 
model contains the corresponding element of the list. Please note that inside 
populateItem we must add nested components to the @item@ object and not 
directly to the @ListView@.
+
+h3. ListView and Form
+
+By default @ListView@ replaces its children components with new instances 
every time is rendered. Unfortunately this behavior is a problem if @ListView@ 
is inside a form and it contains form components. The problem is caused by the 
fact that children components are replaced by new ones before form is rendered, 
hence they can't keep their input value if validation fails and, furthermore, 
their feedback messages can not be displayed.
+
+To avoid this kind of problem we can force @ListView@ to reuse its children 
components using its method setReuseItems and passing true as parameter. If for 
any reason we need to refresh children components after we have invoked 
setReuseItems(true), we can use MarkupContainer's method @removeAll()@ to force 
@ListView@ to rebuild them.
\ No newline at end of file

Reply via email to