[03/21] wicket git commit: Removes gdoc infrastructure, adds asciidoctor files

Fri, 18 Nov 2016 06:51:18 -0800 

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/single.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/single.adoc 
b/wicket-user-guide/src/main/asciidoc/single.adoc
new file mode 100644
index 0000000..f320bdc
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/single.adoc
@@ -0,0 +1,868 @@
+= Wicket 8.x Reference Guide
+The Apache Software Foundation
+:toc: left
+:icons: font
+:sectlinks:
+
+:sectnums:
+
+== Introduction
+
+include::introduction.adoc[]
+
+== How to use the example code
+
+include::howToSource.adoc[]
+
+== Why should I learn Wicket?
+
+include::whyLearn.adoc[]
+
+=== We all like spaghetti :-) ...
+
+include::whyLearn/whyLearn_1.adoc[leveloffset=+1]
+
+=== Component oriented frameworks - an overview
+
+include::whyLearn/whyLearn_2.adoc[leveloffset=+1]
+
+=== Benefits of component oriented frameworks for web development
+
+include::whyLearn/whyLearn_3.adoc[leveloffset=+1]
+
+=== Wicket vs the other component oriented frameworks
+
+include::whyLearn/whyLearn_4.adoc[leveloffset=+1]
+
+== Wicket says “Hello world!”
+
+include::helloWorld.adoc[]
+
+=== Wicket distribution and modules
+
+include::helloWorld/helloWorld_1.adoc[leveloffset=+1]
+
+=== Configuration of Wicket applications
+
+include::helloWorld/helloWorld_2.adoc[leveloffset=+1]
+
+=== The HomePage class
+
+include::helloWorld/helloWorld_3.adoc[leveloffset=+1]
+
+=== Wicket Links
+
+include::helloWorld/helloWorld_4.adoc[leveloffset=+1]
+
+=== Summary
+
+include::helloWorld/helloWorld_5.adoc[leveloffset=+1]
+
+== Wicket as page layout manager
+
+include::layout.adoc[]
+
+=== Header, footer, left menu, content, etc...
+
+include::layout/layout_1.adoc[leveloffset=+1]
+
+=== Here comes the inheritance!
+
+include::layout/layout_2.adoc[leveloffset=+1]
+
+=== Divide et impera!
+
+include::layout/layout_3.adoc[leveloffset=+1]
+
+=== Markup inheritance with the wicket:extend tag
+
+include::layout/layout_4.adoc[leveloffset=+1]
+
+=== Summary
+
+include::layout/layout_5.adoc[leveloffset=+1]
+
+== Keeping control over HTML
+
+include::keepControl.adoc[]
+
+=== Hiding or disabling a component
+
+include::keepControl/keepControl_1.adoc[leveloffset=+1]
+
+=== Modifing tag attributes
+
+include::keepControl/keepControl_2.adoc[leveloffset=+1]
+
+=== Generating tag attribute 'id'
+
+include::keepControl/keepControl_3.adoc[leveloffset=+1]
+
+=== Creating in-line panels with WebMarkupContainer
+
+include::keepControl/keepControl_4.adoc[leveloffset=+1]
+
+=== Working with markup fragments
+
+include::keepControl/keepControl_5.adoc[leveloffset=+1]
+
+=== Adding header contents to the final page
+
+include::keepControl/keepControl_6.adoc[leveloffset=+1]
+
+=== Using stub markup in our pages/panels
+
+include::keepControl/keepControl_7.adoc[leveloffset=+1]
+
+=== How to render component body only
+
+include::keepControl/keepControl_8.adoc[leveloffset=+1]
+
+=== Hiding decorating elements with the wicket:enclosure tag
+
+include::keepControl/keepControl_9.adoc[leveloffset=+1]
+
+=== Surrounding existing markup with Border
+
+include::keepControl/keepControl_10.adoc[leveloffset=+1]
+
+=== Summary
+
+include::keepControl/keepControl_11.adoc[leveloffset=+1]
+
+== Components lifecycle
+
+include::componentLifecycle.adoc[]
+
+=== Lifecycle stages of a component
+
+include::componentLifecycle/componentLifecycle_1.adoc[leveloffset=+1]
+
+=== Hook methods for component lifecycle
+
+include::componentLifecycle/componentLifecycle_2.adoc[leveloffset=+1]
+
+=== Initialization stage
+
+include::componentLifecycle/componentLifecycle_3.adoc[leveloffset=+1]
+
+=== Rendering stage
+
+include::componentLifecycle/componentLifecycle_4.adoc[leveloffset=+1]
+
+=== Removing stage
+
+include::componentLifecycle/componentLifecycle_5.adoc[leveloffset=+1]
+
+=== Summary
+
+include::componentLifecycle/componentLifecycle_6.adoc[leveloffset=+1]
+
+== Page versioning and caching
+
+include::versioningCaching.adoc[]
+
+=== Stateful pages vs stateless
+
+include::versioningCaching/versioningCaching_1.adoc[leveloffset=+1]
+
+=== Stateful pages
+
+include::versioningCaching/versioningCaching_2.adoc[leveloffset=+1]
+
+=== Stateless pages
+
+include::versioningCaching/versioningCaching_3.adoc[leveloffset=+1]
+
+=== Summary
+
+include::versioningCaching/versioningCaching_4.adoc[leveloffset=+1]
+
+== Under the hood of the request processing
+
+include::requestProcessing.adoc[]
+
+=== Class Application and request processing
+
+include::requestProcessing/requestProcessing_1.adoc[leveloffset=+1]
+
+=== Request and Response classes
+
+include::requestProcessing/requestProcessing_2.adoc[leveloffset=+1]
+
+=== The “director” of request processing - RequestCycle
+
+include::requestProcessing/requestProcessing_3.adoc[leveloffset=+1]
+
+=== Session Class
+
+include::requestProcessing/requestProcessing_4.adoc[leveloffset=+1]
+
+=== Exception handling
+
+include::requestProcessing/requestProcessing_5.adoc[leveloffset=+1]
+
+=== Summary
+
+include::requestProcessing/requestProcessing_6.adoc[leveloffset=+1]
+
+== Wicket Links and URL generation
+
+include::urls.adoc[]
+
+=== PageParameters
+
+include::urls/urls_1.adoc[leveloffset=+1]
+
+=== Bookmarkable links
+
+include::urls/urls_2.adoc[leveloffset=+1]
+
+=== Automatically creating bookmarkable links with tag wicket:link
+
+include::urls/urls_3.adoc[leveloffset=+1]
+
+=== External links
+
+include::urls/urls_4.adoc[leveloffset=+1]
+
+=== Stateless links
+
+include::urls/urls_5.adoc[leveloffset=+1]
+
+=== Generating structured and clear URLs
+
+include::urls/urls_6.adoc[leveloffset=+1]
+
+=== Summary
+
+include::urls/urls_7.adoc[leveloffset=+1]
+
+== Wicket models and forms
+
+include::modelsforms.adoc[]
+
+=== What is a model?
+
+include::modelsforms/modelsforms_1.adoc[leveloffset=+1]
+
+=== IModel and Lambda
+
+include::modelsforms/modelsforms_2.adoc[leveloffset=+1]
+
+=== Models and JavaBeans
+
+include::modelsforms/modelsforms_3.adoc[leveloffset=+1]
+
+=== Wicket forms
+
+include::modelsforms/modelsforms_4.adoc[leveloffset=+1]
+
+=== Component DropDownChoice
+
+include::modelsforms/modelsforms_5.adoc[leveloffset=+1]
+
+=== Model chaining
+
+include::modelsforms/modelsforms_6.adoc[leveloffset=+1]
+
+=== Detachable models
+
+include::modelsforms/modelsforms_7.adoc[leveloffset=+1]
+
+=== Using more than one model in a component
+
+include::modelsforms/modelsforms_8.adoc[leveloffset=+1]
+
+=== Use models!
+
+include::modelsforms/modelsforms_9.adoc[leveloffset=+1]
+
+=== Summary
+
+include::modelsforms/modelsforms_10.adoc[leveloffset=+1]
+
+== Wicket forms in detail
+
+include::forms2.adoc[]
+
+=== Default form processing
+
+include::forms2/forms2_1.adoc[leveloffset=+1]
+
+=== Form validation and feedback messages
+
+include::forms2/forms2_2.adoc[leveloffset=+1]
+
+=== Input value conversion
+
+include::forms2/forms2_3.adoc[leveloffset=+1]
+
+=== Validation with JSR 303
+
+include::forms2/forms2_4.adoc[leveloffset=+1]
+
+=== Submit form with an IFormSubmittingComponent
+
+include::forms2/forms2_5.adoc[leveloffset=+1]
+
+=== Nested forms
+
+include::forms2/forms2_6.adoc[leveloffset=+1]
+
+=== Multi-line text input
+
+include::forms2/forms2_7.adoc[leveloffset=+1]
+
+=== File upload
+
+include::forms2/forms2_8.adoc[leveloffset=+1]
+
+=== Creating complex form components with FormComponentPanel
+
+include::forms2/forms2_9.adoc[leveloffset=+1]
+
+=== Stateless form
+
+include::forms2/forms2_10.adoc[leveloffset=+1]
+
+=== Working with radio buttons and checkboxes
+
+include::forms2/forms2_11.adoc[leveloffset=+1]
+
+=== Selecting multiple values with ListMultipleChoices and Palette
+
+include::forms2/forms2_12.adoc[leveloffset=+1]
+
+=== Summary
+
+include::forms2/forms2_13.adoc[leveloffset=+1]
+
+== Displaying multiple items with repeaters
+
+include::repeaters.adoc[]
+
+=== The RepeatingView Component
+
+include::repeaters/repeaters_1.adoc[leveloffset=+1]
+
+=== The ListView Component
+
+include::repeaters/repeaters_2.adoc[leveloffset=+1]
+
+=== The RefreshingView Component
+
+include::repeaters/repeaters_3.adoc[leveloffset=+1]
+
+=== Pageable repeaters
+
+include::repeaters/repeaters_4.adoc[leveloffset=+1]
+
+=== Summary
+
+include::repeaters/repeaters_5.adoc[leveloffset=+1]
+
+== Component queueing
+
+include::componentQueueing.adoc[]
+
+=== Markup hierarchy and code
+
+include::componentQueueing/componentQueueing_1.adoc[leveloffset=+1]
+
+=== Improved auto components
+
+include::componentQueueing/componentQueueing_2.adoc[leveloffset=+1]
+
+=== When are components dequeued?
+
+include::componentQueueing/componentQueueing_3.adoc[leveloffset=+1]
+
+=== Restrictions of queueing
+
+include::componentQueueing/componentQueueing_4.adoc[leveloffset=+1]
+
+=== Summary
+
+include::componentQueueing/componentQueueing_5.adoc[leveloffset=+1]
+
+== Internationalization with Wicket
+
+include::i18n.adoc[]
+
+=== Localization
+
+include::i18n/i18n_1.adoc[leveloffset=+1]
+
+=== Localization in Wicket
+
+include::i18n/i18n_2.adoc[leveloffset=+1]
+
+=== Bundles lookup algorithm
+
+include::i18n/i18n_3.adoc[leveloffset=+1]
+
+=== Localization of component's choices
+
+include::i18n/i18n_4.adoc[leveloffset=+1]
+
+=== Internationalization and Models
+
+include::i18n/i18n_5.adoc[leveloffset=+1]
+
+=== Summary
+
+include::i18n/i18n_6.adoc[leveloffset=+1]
+
+== Resource management with Wicket
+
+include::resources.adoc[]
+
+=== Static vs dynamic resources
+
+include::resources/resources_1.adoc[leveloffset=+1]
+
+=== Resource references
+
+include::resources/resources_2.adoc[leveloffset=+1]
+
+=== Package resources
+
+include::resources/resources_3.adoc[leveloffset=+1]
+
+=== Adding resources to page header section
+
+include::resources/resources_4.adoc[leveloffset=+1]
+
+=== Context-relative resources
+
+include::resources/resources_5.adoc[leveloffset=+1]
+
+=== Resource dependencies
+
+include::resources/resources_6.adoc[leveloffset=+1]
+
+=== Aggregate multiple resources with resource bundles
+
+include::resources/resources_7.adoc[leveloffset=+1]
+
+=== Put JavaScript inside page body
+
+include::resources/resources_8.adoc[leveloffset=+1]
+
+=== Header contributors positioning
+
+include::resources/resources_9.adoc[leveloffset=+1]
+
+=== Custom resources
+
+include::resources/resources_10.adoc[leveloffset=+1]
+
+=== Mounting resources
+
+include::resources/resources_11.adoc[leveloffset=+1]
+
+=== Shared resources
+
+include::resources/resources_12.adoc[leveloffset=+1]
+
+=== Customizing resource loading
+
+include::resources/resources_13.adoc[leveloffset=+1]
+
+=== CssHeaderItem and JavaScriptHeaderItem compression
+
+include::resources/resources_14.adoc[leveloffset=+1]
+
+=== NIO resources
+
+include::resources/resources_15.adoc[leveloffset=+1]
+
+=== Resourcen derived through models
+
+include::resources/resources_16.adoc[leveloffset=+1]
+
+=== Summary
+
+include::resources/resources_17.adoc[leveloffset=+1]
+
+== An example of integration with JavaScript
+
+include::jsintegration.adoc[]
+
+=== What we want to do...
+
+include::jsintegration/jsintegration_1.adoc[leveloffset=+1]
+
+=== ...and how we will do it
+
+include::jsintegration/jsintegration_2.adoc[leveloffset=+1]
+
+=== Summary
+
+include::jsintegration/jsintegration_3.adoc[leveloffset=+1]
+
+== Wicket advanced topics
+
+include::advanced.adoc[]
+
+=== Enriching components with behaviors
+
+include::advanced/advanced_1.adoc[leveloffset=+1]
+
+=== Generating callback URLs with IRequestListener
+
+include::advanced/advanced_2.adoc[leveloffset=+1]
+
+=== Wicket events infrastructure
+
+include::advanced/advanced_3.adoc[leveloffset=+1]
+
+=== Initializers
+
+include::advanced/advanced_4.adoc[leveloffset=+1]
+
+=== Using JMX with Wicket
+
+include::advanced/advanced_5.adoc[leveloffset=+1]
+
+=== Generating HTML markup from code
+
+include::advanced/advanced_6.adoc[leveloffset=+1]
+
+=== Summary
+
+include::advanced/advanced_7.adoc[leveloffset=+1]
+
+== Working with AJAX
+
+include::ajax.adoc[]
+
+=== How to use AJAX components and behaviors
+
+include::ajax/ajax_1.adoc[leveloffset=+1]
+
+=== Build-in AJAX components
+
+include::ajax/ajax_2.adoc[leveloffset=+1]
+
+=== Built-in AJAX behaviors
+
+include::ajax/ajax_3.adoc[leveloffset=+1]
+
+=== Using an activity indicator
+
+include::ajax/ajax_4.adoc[leveloffset=+1]
+
+=== AJAX request attributes and call listeners
+
+include::ajax/ajax_5.adoc[leveloffset=+1]
+
+=== Creating custom AJAX call listener
+
+include::ajax/ajax_6.adoc[leveloffset=+1]
+
+=== Stateless AJAX components/behaviors
+
+include::ajax/ajax_7.adoc[leveloffset=+1]
+
+=== Lambda support
+
+include::ajax/ajax_8.adoc[leveloffset=+1]
+
+=== Summary
+
+include::ajax/ajax_9.adoc[leveloffset=+1]
+
+== Integration with enterprise containers
+
+include::jee.adoc[]
+
+=== Integrating Wicket with EJB
+
+include::jee/jee_1.adoc[leveloffset=+1]
+
+=== Integrating Wicket with Spring
+
+include::jee/jee_2.adoc[leveloffset=+1]
+
+=== JSR-330 annotations
+
+include::jee/jee_3.adoc[leveloffset=+1]
+
+=== Summary
+
+include::jee/jee_4.adoc[leveloffset=+1]
+
+== Native WebSockets
+
+include::nativewebsockets.adoc[]
+
+=== How does it work ?
+
+include::nativewebsockets/nativewebsockets_1.adoc[leveloffset=+1]
+
+=== How to use
+
+include::nativewebsockets/nativewebsockets_2.adoc[leveloffset=+1]
+
+=== Client-side APIs
+
+include::nativewebsockets/nativewebsockets_3.adoc[leveloffset=+1]
+
+=== Testing
+
+include::nativewebsockets/nativewebsockets_4.adoc[leveloffset=+1]
+
+=== Differences with Wicket-Atmosphere module.
+
+include::nativewebsockets/nativewebsockets_5.adoc[leveloffset=+1]
+
+=== FAQ
+
+include::nativewebsockets/nativewebsockets_6.adoc[leveloffset=+1]
+
+== Security with Wicket
+
+include::security.adoc[]
+
+=== Authentication
+
+include::security/security_1.adoc[leveloffset=+1]
+
+=== Authorizations
+
+include::security/security_2.adoc[leveloffset=+1]
+
+=== Using HTTPS protocol
+
+include::security/security_3.adoc[leveloffset=+1]
+
+=== URLs encryption in detail
+
+include::security/security_4.adoc[leveloffset=+1]
+
+=== CSRF protection
+
+include::security/security_4_1.adoc[leveloffset=+1]
+
+=== Package Resource Guard
+
+include::security/security_5.adoc[leveloffset=+1]
+
+=== External Security Checks
+
+include::security/security_6.adoc[leveloffset=+1]
+
+=== Summary
+
+include::security/security_7.adoc[leveloffset=+1]
+
+== Test Driven Development with Wicket
+
+include::testing.adoc[]
+
+=== Utility class WicketTester
+
+include::testing/testing_1.adoc[leveloffset=+1]
+
+=== Testing Wicket forms
+
+include::testing/testing_2.adoc[leveloffset=+1]
+
+=== Testing markup with TagTester
+
+include::testing/testing_3.adoc[leveloffset=+1]
+
+=== Summary
+
+include::testing/testing_4.adoc[leveloffset=+1]
+
+== Test Driven Development with Wicket and Spring
+
+include::testingspring.adoc[]
+
+=== Configuration of the runtime environment
+
+include::testingspring/testingspring_1.adoc[leveloffset=+1]
+
+=== Configuration of the JUnit based integration test environment
+
+include::testingspring/testingspring_2.adoc[leveloffset=+1]
+
+=== Summary
+
+include::testingspring/testingspring_3.adoc[leveloffset=+1]
+
+== Wicket Best Practices
+
+include::bestpractices.adoc[]
+
+=== Encapsulate components correctly
+
+include::bestpractices/bestpractices_1.adoc[leveloffset=+1]
+
+=== Put models and page data in fields
+
+include::bestpractices/bestpractices_2.adoc[leveloffset=+1]
+
+=== Correct naming for Wicket IDs
+
+include::bestpractices/bestpractices_3.adoc[leveloffset=+1]
+
+=== Avoid changes at the component tree
+
+include::bestpractices/bestpractices_4.adoc[leveloffset=+1]
+
+=== Implement visibilities of components correctly
+
+include::bestpractices/bestpractices_5.adoc[leveloffset=+1]
+
+=== Always use models
+
+include::bestpractices/bestpractices_6.adoc[leveloffset=+1]
+
+=== Do not unwrap models within the constructor hierarchy
+
+include::bestpractices/bestpractices_7.adoc[leveloffset=+1]
+
+=== Pass models extended components
+
+include::bestpractices/bestpractices_8.adoc[leveloffset=+1]
+
+=== Validators must not change any data or models
+
+include::bestpractices/bestpractices_9.adoc[leveloffset=+1]
+
+=== Do not pass components to constructors
+
+include::bestpractices/bestpractices_10.adoc[leveloffset=+1]
+
+=== Use the Wicket session only for global data
+
+include::bestpractices/bestpractices_11.adoc[leveloffset=+1]
+
+=== Do not use factories for components
+
+include::bestpractices/bestpractices_12.adoc[leveloffset=+1]
+
+=== Every page and component must be tested
+
+include::bestpractices/bestpractices_13.adoc[leveloffset=+1]
+
+=== Avoid interactions with other servlet filters
+
+include::bestpractices/bestpractices_14.adoc[leveloffset=+1]
+
+=== Cut small classes and methods
+
+include::bestpractices/bestpractices_15.adoc[leveloffset=+1]
+
+=== The argument "Bad documentation"
+
+include::bestpractices/bestpractices_16.adoc[leveloffset=+1]
+
+=== Summary
+
+include::bestpractices/bestpractices_17.adoc[leveloffset=+1]
+
+== Wicket Internals
+
+include::internals.adoc[]
+
+=== Page storing
+
+include::internals/pagestoring.adoc[leveloffset=+1]
+
+=== Markup parsing and Autocomponents
+
+include::internals/autocomponents.adoc[leveloffset=+1]
+
+== Wicket HTTP/2 Support (Experimental)
+
+include::http2push.adoc[]
+
+=== Example Usage
+
+include::http2push/http2push_1.adoc[leveloffset=+3]
+
+=== Create server specific http/2 push support
+
+include::http2push/http2push_2.adoc[leveloffset=+3]
+
+== Wicket Metrics Monitoring (Experimental)
+
+include::monitoring.adoc[]
+
+=== Example setup
+
+include::monitoring/monitoring_1.adoc[leveloffset=+1]
+
+=== Visualization with Graphite
+
+include::monitoring/monitoring_2.adoc[leveloffset=+1]
+
+=== Measured data
+
+include::monitoring/monitoring_3.adoc[leveloffset=+1]
+
+=== Write own measurements
+
+include::monitoring/monitoring_4.adoc[leveloffset=+1]
+
+[appendix]
+== Working with Maven
+
+include::maven.adoc[]
+
+=== Switching Wicket to DEPLOYMENT mode
+
+include::maven/maven_1.adoc[leveloffset=+1]
+
+=== Creating a Wicket project from scratch and importing it into our favourite 
IDE
+
+include::maven/maven_2.adoc[leveloffset=+1]
+
+[appendix]
+== Project WicketStuff
+
+include::wicketstuff.adoc[]
+
+=== What is project WicketStuff
+
+include::wicketstuff/wicketstuff_1.adoc[leveloffset=+1]
+
+=== Module tinymce
+
+include::wicketstuff/wicketstuff_2.adoc[leveloffset=+1]
+
+=== Module wicketstuff-gmap3
+
+include::wicketstuff/wicketstuff_3.adoc[leveloffset=+1]
+
+=== Module wicketstuff-googlecharts
+
+include::wicketstuff/wicketstuff_4.adoc[leveloffset=+1]
+
+=== Module wicketstuff-inmethod-grid
+
+include::wicketstuff/wicketstuff_5.adoc[leveloffset=+1]
+
+=== Module wicketstuff-rest-annotations
+
+include::wicketstuff/wicketstuff_6.adoc[leveloffset=+1]
+
+=== Module stateless
+
+include::wicketstuff/wicketstuff_7.adoc[leveloffset=+1]
+
+[appendix]
+== Lost In Redirection With Apache Wicket
+
+include::redirects.adoc[]
+
+[appendix]
+== Contributing to this guide
+
+include::contributing.adoc[]
+

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/testing.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/testing.adoc 
b/wicket-user-guide/src/main/asciidoc/testing.adoc
new file mode 100644
index 0000000..d3f4ab6
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/testing.adoc
@@ -0,0 +1,6 @@
+
+ http://en.wikipedia.org/wiki/Test-driven_development[Test Driven Development] 
has become a crucial activity for every modern development methodology. This 
chapter will cover the built-in support for testing provided by Wicket with its 
rich set of helper and mock classes that allows us to test our components and 
our applications in isolation (i.e without the need for a servlet container) 
using JUnit, the de facto standard for Java unit testing. 
+
+In this chapter we will see how to write unit tests for our applications and 
components and we will learn how to use helper classes to simulate user 
navigation and write acceptance tests without the need of any testing framework 
other than JUnit.
+
+The JUnit version used in this chapter is 4.x.   

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/testing/testing_1.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/testing/testing_1.adoc 
b/wicket-user-guide/src/main/asciidoc/testing/testing_1.adoc
new file mode 100644
index 0000000..e221f3a
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/testing/testing_1.adoc
@@ -0,0 +1,287 @@
+
+
+
+A good way to start getting confident with Wicket unit testing support is 
looking at the test case class _TestHomePage_ that is automatically generated 
by Maven when we use Wicket archetype to create a new project:
+
+image::../img/mvn-wicket-archetype.png[]
+
+Here is the content of TestHomePage:
+
+[source,java]
+----
+public class TestHomePage{
+       private WicketTester tester;
+
+       @Before
+       public void setUp(){
+               tester = new WicketTester(new WicketApplication());
+       }
+       @Test
+       public void homepageRendersSuccessfully(){
+               //start and render the test page
+               tester.startPage(HomePage.class);
+               //assert rendered page class
+               tester.assertRenderedPage(HomePage.class);
+       }
+}
+----
+
+The central class in a Wicket testing is 
_org.apache.wicket.util.tester.WicketTester_. This utility class provides a set 
of methods to render a component, click links, check if page contains a given 
component or a feedback message, and so on.
+
+The basic test case shipped with _TestHomePage_ illustrates how _WicketTester_ 
is typically instantiated (inside method _setUp()_). In order to test our 
components, WicketTester needs to use an instance of _WebApplication_. Usually, 
we will use our application class as _WebApplication_, but we can also decide 
to build WicketTester invoking its no-argument constructor and letting it 
automatically build a mock web application (an instance of class 
_org.apache.wicket.mock.MockApplication_).
+
+The code from _TestHomePage_ introduces two basic methods to test our pages. 
The first is method _startPage_ that renders a new instance of the given page 
class and sets it as current rendered page for WicketTester. The second method 
is assertRenderedPage which checks if the current rendered page is an instance 
of the given class. In this way if TestHomePage succeeds we are sure that page 
HomePage has been rendered without any problem. The last rendered page can be 
retrieved with method _getLastRenderedPage_.
+
+That's only a taste of what _WicketTester_ can do. In the next paragraphs we 
will see how it can be used to test every element that composes a Wicket page 
(links, models, behaviors, etc...).
+
+=== Testing links
+
+A click on a Wicket link can be simulated with method _clickLink_ which takes 
in input the link component or the page-relative path to it.
+
+To see an example of usage of clickLink, let's consider again project 
_LifeCycleStagesRevisited_. As we know from chapter 5 the home page of the 
project alternately displays two different labels (“First label” and 
“Second label”), swapping between them each time button  [reload] is 
clicked. The code from its test case checks that label has actually changed 
after button  [reload] has been pressed:
+
+[source,java]
+----
+//...
+@Test
+public void switchLabelTest(){
+       //start and render the test page
+       tester.startPage(HomePage.class);
+       //assert rendered page class
+       tester.assertRenderedPage(HomePage.class);
+       //assert rendered label
+       tester.assertLabel("label", "First label");
+       //simulate a click on "reload" button
+       tester.clickLink("reload");
+       //assert rendered label
+       tester.assertLabel("label", "Second label");    
+}
+//...
+----
+
+In the code above we have used _clickLink_ to click on the  [reload] button 
and force page to be rendered again. In addition, we have used also method 
_assertLabel_ that checks if a given label contains the expected text.
+
+By default _clickLink_ assumes that AJAX is enabled on client side. To switch 
AJAX off we can use another version of this method that takes in input the path 
to the link component and a boolean flag that indicates if AJAX must be enabled 
(true) or not (false). 
+
+[source,java]
+----
+//...
+//simulate a click on a button without AJAX support
+tester.clickLink("reload", false);
+//...
+----
+
+=== Testing component status
+
+WicketTester provides also a set of methods to test the states of a component. 
They are:
+
+* *assertEnabled(String path)/assertDisabled(String path)*: they test if a 
component is enabled or not.
+* *assertVisible(String path)/assertInvisible(String path)*: they test 
component visibility.
+* *assertRequired(String path)*: checks if a form component is required.
+
+In the test case from project _CustomDatepickerAjax_ we used 
_assertEnabled_/_assertDisabled_ to check if button  [update] really disables 
our datepicker:  
+
+[source,java]
+----
+//...
+@Test
+public void testDisableDatePickerWithButton(){
+       //start and render the test page
+       tester.startPage(HomePage.class);
+       //assert that datepicker is enabled
+       tester.assertEnabled("form:datepicker");
+       //click on update button to disable datepicker
+       tester.clickLink("update");
+       //assert that datepicker is disabled
+       tester.assertDisabled("form:datepicker");               
+}
+//...
+----
+
+=== Testing components in isolation
+
+Method _startComponent(Component)_ can be used to test a component in 
isolation without having to create a container page for this purpose. The 
target component is rendered and both its methods _onInitialize()_ and 
_onBeforeRender()_ are executed. In the test case from project 
_CustomFormComponentPanel_ we used this method to check if our custom form 
component correctly renders its internal label:
+
+[source,java]
+----
+//...
+@Test
+public void testCustomPanelContainsLabel(){
+       TemperatureDegreeField field = new TemperatureDegreeField("field", 
Model.of(0.00));
+       //Use standard JUnit class Assert       
+       Assert.assertNull(field.get("mesuramentUnit"));         
+       tester.startComponent(field);           
+       Assert.assertNotNull(field.get("mesuramentUnit"));
+}
+//...
+----
+
+If test requires a page we can use _startComponentInPage(Component)_ which 
automatically generates a page for our component.
+
+=== Testing the response
+
+_WicketTester_ allows us to access to the last response generated during 
testing with method _getLastResponse_. The returned value is an instance of 
class MockHttpServletResponse that provides helper methods to extract 
informations from mocked request. 
+
+In the test case from project _CustomResourceMounting_ we extract the text 
contained in the last response with method _getDocument_ and we check if it is 
equal to the RSS feed used for the test: 
+
+[source,java]
+----
+//...
+@Test
+public void testMountedResourceResponse() throws IOException, 
FeedException{tester.startResource(new RSSProducerResource());
+       String responseTxt = tester.getLastResponse().getDocument();
+       //write the RSS feed used in the test into a ByteArrayOutputStream
+       ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
+       Writer writer = new OutputStreamWriter(outputStream);
+       SyndFeedOutput output = new SyndFeedOutput();
+               
+       output.output(RSSProducerResource.getFeed(), writer);
+       //the response and the RSS must be equal 
+       Assert.assertEquals(responseTxt, outputStream.toString());
+}
+//...
+----
+
+To simulate a request to the custom resource we used method _startResource_ 
which can be used also with resource references.
+
+=== Testing URLs
+
+_WicketTester_ can be pointed to an arbitrary URL with method 
_executeUrl(String url)_. This can be useful to test mounted pages, resources 
or request mappers:
+
+[source,java]
+----
+//...
+//the resource was mapped at '/foo/bar'
+tester.executeUrl("./foo/bar");        
+//...
+----
+
+=== Testing AJAX components
+
+If our application uses AJAX to refresh components markup, we can test if 
_AjaxRequestTarget_ contains a given component with _WicketTester_'s method 
_assertComponentOnAjaxResponse_:
+
+[source,java]
+----
+//...
+//test if AjaxRequestTarget contains a component (using its instance)
+tester.assertComponentOnAjaxResponse(amountLabel);     
+//...
+//test if AjaxRequestTarget contains a component (using its path)
+tester.assertComponentOnAjaxResponse("pathToLabel:labelId");
+----
+
+It's also possible to use method _isComponentOnAjaxResponse(Component cmp)_ to 
know if a component has been added to _AjaxRequestTarget_:
+
+[source,java]
+----
+//...
+//test if AjaxRequestTarget does NOT contain amountLabel 
+assertFalse(tester.isComponentOnAjaxResponse(amountLabel));    
+//...
+----
+
+=== Testing AJAX events
+
+Behavior _AjaxEventBehavior_ and its subclasses can be tested simulating AJAX 
events with _WicketTester_'s method _executeAjaxEvent(Component cmp, String 
event)_. Here is the sample code from project _TestAjaxEventsExample_:
+
+*Home page code:*
+
+[source,java]
+----
+public class HomePage extends WebPage {
+ public static String INIT_VALUE = "Initial value";
+ public static String OTHER_VALUE = "Other value";
+       
+ public HomePage(final PageParameters parameters) {
+       super(parameters);
+       Label label;
+       add(label = new Label("label", INIT_VALUE));                            
+       label.add(new AjaxEventBehavior("click") {
+                       
+               @Override
+               protected void onEvent(AjaxRequestTarget target) {
+                       //change label's data object
+                       getComponent().setDefaultModelObject(
+                                                  OTHER_VALUE);
+                       target.add(getComponent());
+               }
+       }).setOutputMarkupId(true);
+       //...
+ }
+}
+----
+
+*Test method:*
+
+[source,java]
+----
+@Test
+public void testAjaxBehavior(){
+       //start and render the test page
+       tester.startPage(HomePage.class);
+       //test if label has the initial expected value
+       tester.assertLabel("label", HomePage.INIT_VALUE);               
+       //simulate an AJAX "click" event
+       tester.executeAjaxEvent("label", "click");
+       //test if label has changed as expected
+       tester.assertLabel("label", HomePage.OTHER_VALUE);
+}
+----
+
+=== Testing AJAX behaviors
+
+To test a generic AJAX behavior we can simulate a request to it using 
_WicketTester_'s method _executeBehavior(AbstractAjaxBehavior behavior)_:
+
+[source,java]
+----
+//...
+AjaxFormComponentUpdatingBehavior ajaxBehavior = 
+               new AjaxFormComponentUpdatingBehavior("change"){
+       @Override
+       protected void onUpdate(AjaxRequestTarget target) {
+               //...                           
+       }
+};
+component.add(ajaxBehavior);
+//...
+//execute AJAX behavior, i.e. onUpdate will be invoked 
+tester.executeBehavior(ajaxBehavior)); 
+//...
+----
+
+=== Using a custom servlet context
+
+In [paragraph 16.13|guide:resources_13] we have seen how to configure our 
application to store resource files into a custom folder placed inside webapp 
root folder (see project _CustomFolder4MarkupExample_). 
+
+In order to write testing code for applications that use this kind of 
customization, we must tell _WicketTester_ which folder to use as webapp root. 
This is necessary as under test environment we don't have any web server, hence 
it's impossible for _WicketTester_ to retrieve this parameter from servlet 
context.
+
+Webapp root folder can be passed to _WicketTester_'s constructor as further 
parameter like we did in the test case of project _CustomFolder4MarkupExample_:
+
+[source,java]
+----
+public class TestHomePage{
+   private WicketTester tester;
+
+   @Before
+   public void setUp(){
+      //build the path to webapp root folder   
+      File curDirectory = new File(System.getProperty("user.dir"));
+      File webContextDir = new File(curDirectory, "src/main/webapp");
+      
+      tester = new WicketTester(new WicketApplication(), 
webContextDir.getAbsolutePath());
+   }
+   //test methods...
+}
+----
+
+NOTE: After a test method has been executed, we may need to clear any possible 
side effect occurred to the _Application_ and _Session_ objects. This can be 
done invoking _WicketTester_'s method _destroy()_:
+
+[source,java]
+----
+@After
+public void tearDown(){
+       //clear any side effect occurred during test.
+       tester.destroy();
+}
+----
+

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/testing/testing_2.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/testing/testing_2.adoc 
b/wicket-user-guide/src/main/asciidoc/testing/testing_2.adoc
new file mode 100644
index 0000000..a29e94a
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/testing/testing_2.adoc
@@ -0,0 +1,107 @@
+
+
+
+Wicket provides utility class FormTester that is expressly designed to test 
Wicket forms. A new FormTester is returned by _WicketTester_'s method 
_newFormTester(String, boolean)_ which takes in input the page-relative path of 
the form we want to test and a boolean flag indicating if its form components 
must be filled with a blank string:
+
+[source,java]
+----
+//...
+//create a new form tester without filling its form components with a blank 
string
+FormTester formTester = tester.newFormTester("form", false);
+//...
+----
+
+_FormTester_ can simulate form submission with method submit which takes in 
input as optional parameter the submitting component to use instead of the 
default one:
+
+[source,java]
+----
+//...
+//create a new form tester without filling its form components with a blank 
string
+FormTester formTester = tester.newFormTester("form", false);
+//submit form with default submitter
+formTester.submit();
+//...
+//submit form using inner component 'button' as alternate button
+formTester.submit("button");
+----
+
+If we want to submit a form with an external link component we can use method 
_submitLink(String path, boolean pageRelative)_ specifying the path to the link.
+
+In the next paragraphs we will see how to use _WicketTester_ and _FormTester_ 
to interact with a form and with its children components.
+
+=== Setting form components input
+
+The purpose of a HTML form is to collect user input. _FormTester_ comes with 
the following set of methods that simulate input insertion into form's fields:
+
+* *setValue(String path, String value)*: inserts the given textual value into 
the specified component. It can be used with components _TextField_ and 
_TextArea_. A version of this method that accepts a component instance instead 
of its path is also available.
+* *setValue(String checkboxId, boolean value)*: sets the value of a given 
_CheckBox_ component.
+* *setFile(String formComponentId, File file, String contentType)*: sets a 
_File_ object on a _FileUploadField_ component.
+* *select(String formComponentId, int index)*: selects an option among a list 
of possible options owned by a component. It supports components that are 
subclasses of _AbstractChoice_ along with _RadioGroup_ and _CheckGroup_. 
+* *selectMultiple(String formComponentId, int <<_>>
+ indexes)*: selects all the options corresponding to the given array of 
indexes. It can be used with multiple-choice components like _CheckGroup_ or 
_ListMultipleChoice_.
+
+_setValue_ is used inside method _insertUsernamePassword_ to set the username 
and password fields of the form used in project _StatelessLoginForm_:
+
+[source,java]
+----
+protected void insertUsernamePassword(String username, String password) {
+       //start and render the test page
+       tester.startPage(HomePage.class);
+       FormTester formTester = tester.newFormTester("form");
+       //set credentials
+       formTester.setValue("username", username);
+       formTester.setValue("password", password);              
+       //submit form
+       formTester.submit();
+}
+----
+
+=== Testing feedback messages
+
+To check if a page contains one or more expected feedback messages we can use 
the following methods provided by _WicketTester_:
+
+* *assertFeedback(String path, String... messages)*: asserts that a given 
panel contains the specified messages
+* *assertInfoMessages(String... expectedInfoMessages)*: asserts that the 
expected info messages are rendered in the page.
+* *assertErrorMessages(String... expectedErrorMessages)*: asserts that the 
expected error messages are rendered in the page.
+
+_assertInfoMessages_ and _assertErrorMessages_ are used in the test case from 
project _StatelessLoginForm_ to check that form generates a feedback message in 
accordance with the login result:
+
+
+[source,java]
+----
+@Test
+public void testMessageForSuccessfulLogin(){
+       inserUsernamePassword("user", "user");  
+       tester.assertInfoMessages("Username and password are correct!");
+}      
+       
+@Test
+public void testMessageForFailedLogin (){
+       inserUsernamePassword("wrongCredential", "wrongCredential");            
+       tester.assertErrorMessages("Wrong username or password");
+}
+----
+
+=== Testing models
+
+Component model can be tested as well. With method _assertModelValue_ we can 
test if a specific component has the expected data object inside its model.
+
+This method has been used in the test case of project _ModelChainingExample_ 
to check if the form and the drop-down menu share the same data object:
+
+[source,java]
+----
+@Test
+public void testFormSelectSameModelObject(){
+       PersonListDetails personListDetails = new PersonListDetails();
+       DropDownChoice dropDownChoice = (DropDownChoice) 
personListDetails.get("persons");
+       List choices = dropDownChoice.getChoices();
+       //select the second option of the drop-down menu
+       dropDownChoice.setModelObject(choices.get(1));
+       
+       //start and render the test page
+       tester.startPage(personListDetails);            
+       //assert that form has the same data object used by drop-down menu
+       tester.assertModelValue("form", dropDownChoice.getModelObject());
+}
+----
+

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/testing/testing_3.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/testing/testing_3.adoc 
b/wicket-user-guide/src/main/asciidoc/testing/testing_3.adoc
new file mode 100644
index 0000000..e17bd3b
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/testing/testing_3.adoc
@@ -0,0 +1,67 @@
+
+
+
+If we need to test component markup at a more fine-grained level, we can use 
class _TagTester_ from package _org.apache.wicket.util.tester_. 
+
+This test class allows to check if the generated markup contains one or more 
tags having a given attribute with a given value. TagTester can not be directly 
instantiated but it comes with three factory methods that return one or more 
TagTester matching the searching criteria. In the following test case (from 
project _TagTesterExample_) we retrieve the first tag of the home page (a 
<span> tag) having attribute class equal to myClass:
+
+*HomePage markup:*
+
+[source,html]
+----
+<html xmlns:wicket="http://wicket.apache.org";>
+       <head>
+               <meta charset="utf-8" />
+               <title></title>
+       </head>
+       <body>
+               <span class="myClass"></span>
+               <div class="myClass"></div>
+       </body>
+</html>
+----
+
+*Test method:*
+
+[source,java]
+----
+@Test
+public void homePageMarkupTest()
+{
+       //start and render the test page
+       tester.startPage(HomePage.class);
+       //retrieve response's markup
+       String responseTxt = tester.getLastResponse().getDocument();
+
+       TagTester tagTester = TagTester.createTagByAttribute(responseTxt, 
"class", "myClass"); 
+
+       Assert.assertNotNull(tagTester);
+       Assert.assertEquals("span", tagTester.getName());       
+
+       List<TagTester> tagTesterList = 
TagTester.createTagsByAttribute(responseTxt, 
+                                               "class", "myClass", false);
+       
+       Assert.assertEquals(2, tagTesterList.size());
+}
+----
+
+The name of the tag found by TagTester can be retrieved with its method 
getName. Method _createTagsByAttribute_ returns all the tags that have the 
given value on the class attribute. In the code above we have used this method 
to test that our markup contains two tags having attribute class equal to 
myClass.
+
+Another utility class that comes in handy when we want to test components 
markup is _ComponentRenderer_ in package _org.apache.wicket.core.util.string_. 
The purpose of this class is to render a page or a component in isolation with 
its static methods _renderComponent_ and _renderPage_. Both methods return the 
generated markup as _CharSequence_:
+
+[source,java]
+----
+@Test
+public void customComponentMarkupTest()
+{
+       //instantiate MyComponent
+       MyComponent myComponent = //...
+
+       //render and save component markup
+       String componentMarkup = ComponentRenderer.renderComponent(myComponent);
+       
+       //perform test operations
+       //...
+}
+----
+

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/testing/testing_4.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/testing/testing_4.adoc 
b/wicket-user-guide/src/main/asciidoc/testing/testing_4.adoc
new file mode 100644
index 0000000..e8ff64f
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/testing/testing_4.adoc
@@ -0,0 +1,12 @@
+
+
+
+With a component-oriented framework we can test our pages and components as we 
use to do with any other Java entity. Wicket offers a complete support for 
writing testing code, offering built-in tools to test nearly all the elements 
that build up our applications (pages, containers, links, behaviors, etc...).
+
+The main entity discussed in this chapter has been class _WicketTester_ which 
can be used to write unit tests and acceptance tests for our application, but 
we have also seen how to test forms with _FormTester_ and how to inspect markup 
with _TagTester_.
+
+In addition to learning how to use the utility classes provided by Wicket for 
testing, we have also experienced the innovative approach of Wicket to web 
testing that allows to test components in isolation without the need of running 
our tests with a web server and depending only on JUnit as testing framework.
+
+
+
+

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/testingspring.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/testingspring.adoc 
b/wicket-user-guide/src/main/asciidoc/testingspring.adoc
new file mode 100644
index 0000000..54a0662
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/testingspring.adoc
@@ -0,0 +1,3 @@
+
+Since the development of many web applications is mostly based on the Spring 
framework for dependency injection and application configuration in general, 
it's especially important to get these two frameworks running together 
smoothly not only when deployed on a running server instance itself but rather 
during the execution of JUnit based integration tests as well. Thanks to the 
_WicketTester_ API provided by the Wicket framework itself, one can easily 
build high-quality web applications while practicing test driven development 
and providing a decent set of unit and integration tests to be executed with 
each build. As already mentioned previously, integration and configuration of 
our web applications is based on a lightweight Spring container meaning that 
the integration of Spring's _ApplicationContext_ and a WicketTester API is 
essential to get our integration tests running. In order to explain how to 
achieve that integration in an easy and elegant fashion in your integration 
test 
 environment, we'll first take a look at a configuration of these 2 framework 
beauties in a runtime environment.
+

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/testingspring/testingspring_1.adoc
----------------------------------------------------------------------
diff --git 
a/wicket-user-guide/src/main/asciidoc/testingspring/testingspring_1.adoc 
b/wicket-user-guide/src/main/asciidoc/testingspring/testingspring_1.adoc
new file mode 100644
index 0000000..b77358f
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/testingspring/testingspring_1.adoc
@@ -0,0 +1,94 @@
+
+
+
+In order to get the Wicket framework up to speed when your server is up and 
running, you usually configure a _WicketFilter_ instance in your web 
application deployment descriptor file (_web.xml_) while passing it a single 
init parameter called _applicationClassName_ that points to your main 
implementation class extending 
_org.apache.wicket.protocol.http.WebApplication_ where all of your 
application-wide settings and initialization requirements are dealt with:
+
+[source,xml]
+----
+<filter>
+    <filter-name>wicketfilter</filter-name>
+    <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
+    <init-param>
+        <param-name>applicationClassName</param-name>
+        <param-value>com.comsysto.webapp.MyWebApplication</param-value>
+    </init-param>
+</filter>
+----
+
+In case you want to get Wicket application up and running while leaving the 
application configuration and dependency injection issues to the Spring 
container, the configuration to be provided within the deployment descriptor 
looks slightly different though:
+
+[source,xml]
+----
+<web-app>
+    <filter>
+        <filter-name>wicketfilter</filter-name>
+        
<filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
+        <init-param>
+            <param-name>applicationFactoryClassName</param-name>
+            
<param-value>org.apache.wicket.spring.SpringWebApplicationFactory</param-value>
+        </init-param>
+    </filter>
+    <listener>
+        
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
+    </listener>
+    <context-param>
+        <param-name>contextConfigLocation</param-name>
+        <param-value>/WEB-INF/applicationContext.xml</param-value>
+    </context-param>
+</web-app>
+----
+
+The additional configuration part containing listener and context parameter 
definition is a usual Spring container related configuration detail. 
ContextLoaderListener is an implementation of standard Servlet API 
ServletContextListener interface provided by the Spring framework itself and is 
responsible for looking up an according bean definition file(s) specified by 
the context param above and creating an ApplicationContext instance during 
servlet context initialization accordingly. When integrating an 
ApplicationContext instance with Wicket, one of the beans defined in the above 
mentioned Spring bean definition file has to be your own specific extension of 
_org.apache.wicket.protocol.http.WebApplication_. You can either define a 
suitable bean in the bean definition file itself:
+
+[source,xml]
+----
+<beans>
+    <bean id="myWebApp" class="com.comsysto.webapp.MyWebApplication"/>
+</beans>
+----
+
+or use powerful classpath scanning feature of the Spring framework and 
annotate the MyWebApplication implementation with the appropriate _\_Component_ 
annotation accordingly while enabling the Spring container to scan the 
according package(s) of your application for relevant bean definitions:
+
+[source,xml]
+----
+<beans>
+    <context:component-scan base-package="com.comsysto.webapp" />
+    <context:component-scan base-package="com.comsysto.webapp.service" />
+    <context:component-scan base-package="com.comsysto.webapp.repository" />
+</beans>
+----
+
+Either way, if everything goes well, you'll get a pre-configured 
ApplicationContext all set up during the startup of your web container. One of 
the beans in the ApplicationContext will be your own extension of Wicket's 
WebApplication type. SpringWebApplicationFactory implementation provided by the 
Wicket framework itself that you have defined as the 
_applicationFactoryClassName_ in the configuration of your WicketFilter will 
then be used in order to retrieve that very same WebApplication bean out of 
your Spring ApplicationContext. The Factory expects one and only one extension 
of Wicket's very own WebApplication type to be found within the 
ApplicationContext instance at runtime. If no such bean or more than one bean 
extending WebApplication is found in the given ApplicationContext an according 
IllegalStateException will be raised and initialization of your web application 
will fail:
+
+[source,java]
+----
+Map<?,?> beans = 
BeanFactoryUtils.beansOfTypeIncludingAncestors(ac,WebApplication.class, false, 
false);
+if (beans.size() == 0)
+{
+       throw new IllegalStateException("bean of type [" + 
WebApplication.class.getName() +
+                       "] not found");
+}
+if (beans.size() > 1)
+{
+       throw new IllegalStateException("more than one bean of type [" +
+                       WebApplication.class.getName() + "] found, must have 
only one");
+}
+----
+
+After the WebApplication bean has been successfully retrieved from the 
ApplicationContext via SpringWebApplicationFactory, WicketFilter will then, as 
part of its own initialization process, trigger both internalInit() and init() 
methods of the WebApplication bean. The latter one is the exact spot where the 
last piece of the runtime configuration puzzle between Wicket and Spring is to 
be placed :
+
+[source,java]
+----
+@Component
+public class MyWebApplication extends WebApplication {
+    @Override
+    protected void init() {
+        super.init();
+
+        getComponentInstantiationListeners().add(new 
SpringComponentInjector(this));
+    }
+
+}
+----
+
+SpringComponentInjector provided by the Wicket framework enables you to get 
dependencies from the ApplicationContext directly injected into your Wicket 
components by simply annotating these with the according _\_SpringBean_ 
annotation.

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/testingspring/testingspring_2.adoc
----------------------------------------------------------------------
diff --git 
a/wicket-user-guide/src/main/asciidoc/testingspring/testingspring_2.adoc 
b/wicket-user-guide/src/main/asciidoc/testingspring/testingspring_2.adoc
new file mode 100644
index 0000000..f72d4ec
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/testingspring/testingspring_2.adoc
@@ -0,0 +1,139 @@
+
+
+
+One of the main features of Apache Wicket framework is the ability to easily 
write and run plain unit tests for your Pages and all other kinds of Components 
that even include the verification of the rendering process itself by using 
JUnit framework and the WicketTester API only. When using Spring framework for 
application configuration together with Wicket, as we do, you can even use the 
same tools to easily write and run full blown integration tests for your web 
application as well. All you have to do is use  
http://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/testing.html#testcontext-framework[Spring's
 TestContext] framework additionally to configure and run your JUnit based 
integration tests. The Spring Framework provides a set of Spring specific 
annotations that you can use in your integration tests in conjunction with the 
TestContext framework itself in order to easily configure an according 
ApplicationContext instance for your tests as well as for appropria
 te transaction management before, during and after your test execution. 
Following code snippet represents a simple JUnit 4 based test case using 
Spring's specific annotations in order to initialize an ApplicationContext 
instance prior to executing the test itself:
+
+[source,java]
+----
+@RunWith(SpringJUnit4ClassRunner.class)
+@ContextConfiguration(locations = {"classpath:WEB-INF/applicationContext.xml"})
+@TransactionConfiguration(transactionManager = "txManager", defaultRollback = 
false)
+public class LoginPageTest {
+
+    private WicketTester tester;
+
+    @Autowired
+    private ApplicationContext ctx;
+
+    @Autowired
+    private MyWebApplication myWebApplication;
+
+    @Before
+    public void setUp() {
+        tester = new WicketTester(myWebApplication);
+    }
+
+    @Test
+    @Transactional
+    @Rollback(true)
+    public void testRenderMyPage() {
+        tester.startPage(LoginPage.class);
+        tester.assertRenderedPage(LoginPage.class);
+        tester.assertComponent("login", LoginComponent.class);
+    }
+}
+----
+
+By defining three annotations on the class level (see code snippet above) in 
your test, Spring's TestContext framework takes care of preparing and 
initializing an ApplicationContext instance having all the beans defined in the 
according Spring context file as well as the transaction management in case 
your integration test includes some kind of database access. Fields marked with 
_\_Autowired_ annotation will be automatically dependency injected as well so 
that you can easily access and use these for your testing purposes. Since 
MyWebApplication, which extends Wicket's WebApplication type and represents the 
main class of our web application, is also a bean within the ApplicationContext 
managed by Spring, it will also be provided to us by the test framework itself 
and can be easily used in order to initialize a WicketTester instance later on 
during the execution of the test's setUp() method. With this kind of simple, 
annotation based test configuration we are able to run an integrati
 on test that verifies whether a LoginPage gets started and initialized, 
whether the rendering of the page runs smoothly and whether the page itself 
contains a LoginComponent that we possibly need in order to process user's 
login successfully.
+
+When you run this test though, you'll unfortunately get the following 
exception raised:
+
+[source,java]
+----
+java.lang.IllegalStateException: No WebApplicationContext found: no 
ContextLoaderListener registered?
+    at org.springframework.web.context.support.WebApplicationContextUtils.
+       getRequiredWebApplicationContext(WebApplicationContextUtils.java:84)
+    at org.apache.wicket.spring.injection.annot.
+       SpringComponentInjector.<init>(SpringComponentInjector.java:72)
+    at com.comsysto.serviceplatform.uiwebapp.MyWebApplication.
+       initializeSpringComponentInjector(MyWebApplication.java:59)
+    at com.comsysto.serviceplatform.uiwebapp.MyWebApplication.
+       init(MyWebApplication.java:49)
+    at org.apache.wicket.protocol.http.WicketFilter.
+       init(WicketFilter.java:719)
+    at org.apache.wicket.protocol.http.MockWebApplication.
+       <init>(MockWebApplication.java:168)
+    at org.apache.wicket.util.tester.BaseWicketTester.
+       <init>(BaseWicketTester.java:219)
+    at org.apache.wicket.util.tester.WicketTester.
+       <init>(WicketTester.java:325)
+    at org.apache.wicket.util.tester.WicketTester.
+       <init>(WicketTester.java:308)
+----
+
+As you can see above, the Exception gets raised during the initialization of 
the _WicketTester_ instance even before the actual test method gets executed. 
Even though we have applied rather cool and simple annotation based test 
configuration already described and passed in perfectly well prepared 
ApplicationContext instance to the WicketTester instance in the constructor, 
somewhere down the rabbit hole someone complained that no WebApplicationContext 
instance could have been found which seems to be required in order to 
initialize the WicketTester properly.
+
+image::../img/description-of-illegalstate.jpg[]
+
+The problem that we run against here is due to the fact that 
SpringComponentInjector during its own initialization is trying to get hold of 
an according Spring's ApplicationContext instance that would normally be there 
in a runtime environment but does not find any since we are running in a test 
environment currently. SpringComponentInjector delegates to Spring's own 
WebApplicationContextUtils class to retrieve the instance of ApplicationContext 
out of the ServletContext which is perfectly fine for a runtime environment but 
is unfortunately failing in a test environment:
+
+[source,java]
+----
+public static WebApplicationContext 
getRequiredWebApplicationContext(ServletContext sc)
+               throws IllegalStateException {
+
+       WebApplicationContext wac = getWebApplicationContext(sc);
+       if (wac == null) {
+               throw new IllegalStateException("No WebApplicationContext 
found: no ContextLoaderListener registered?");
+       }
+       return wac;
+}
+----
+
+If you still remember we defined a ContextLoaderListener in our web.xml file 
as part of the configuration of our runtime environment that makes sure an 
according WebApplicationContext instance gets initialized and registered 
against the ServletContext properly. Luckily, this problem can easily be solved 
if we slightly change the way we initialize SpringComponentInjector in our main 
MyWebApplication class. Apart from the constructor that we have used so far, 
there is another constructor in the SpringComponentInjector class that expects 
the caller to provide it with an according ApplicationContext instance rather 
than trying to resolve one on its own:
+
+[source,java]
+----
+public SpringComponentInjector(WebApplication webapp, ApplicationContext ctx,
+               boolean wrapInProxies)
+{
+       if (webapp == null)
+       {
+               throw new IllegalArgumentException("Argument [[webapp]] cannot 
be null");
+       }
+
+       if (ctx == null)
+       {
+               throw new IllegalArgumentException("Argument [[ctx]] cannot be 
null");
+       }
+
+       // store context in application's metadata ...
+       webapp.setMetaData(CONTEXT_KEY, new ApplicationContextHolder(ctx));
+
+       // ... and create and register the annotation aware injector
+       InjectorHolder.setInjector(new AnnotSpringInjector(new 
ContextLocator(), wrapInProxies));
+}
+----
+
+In order to use this constructor instead of the one we used previously, we now 
obviously need to get hold of the _ApplicationContext_ instance on our own in 
our _MyWebApplication_ implementation. The easiest way to do this is to use 
Spring's own concept of  
http://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-factory-aware[lifecycle
 callbacks] provided to the beans managed by the Spring container. Since our 
_MyWebApplication_ is also a bean managed by the Spring container at runtime 
(enabled by the classpath scanning and _\_Component_ annotation on a type 
level), we can declare it to implement _ApplicationContextAware_ interface 
which ensures that it gets provided with the _ApplicationContext_ instance that 
it runs in by the Spring container itself during startup.
+
+[source,java]
+----
+public interface ApplicationContextAware {
+
+       void setApplicationContext(ApplicationContext applicationContext) 
throws BeansException;
+
+}
+----
+
+So the relevant parts of _MyWebApplication_ type will now look something like 
the following code snippet:
+
+[source,java]
+----
+@Component
+public class MyWebApplication extends WebApplication implements 
ApplicationContextAware {
+    @Override
+    protected void init() {
+        addComponentInstantiationListener(new SpringComponentInjector(this, 
ctx, true));
+    }
+
+    public void setApplicationContext(ApplicationContext applicationContext) 
throws BeansException {
+        this.ctx = applicationContext;
+    }
+}
+----
+
+For additional clarification of how _MyWebApplication_ now relates to both 
Wicket and Spring framework here is an according class diagram:
+
+image::../img/mywebapp-class-diagramm.jpg[]
+

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/testingspring/testingspring_3.adoc
----------------------------------------------------------------------
diff --git 
a/wicket-user-guide/src/main/asciidoc/testingspring/testingspring_3.adoc 
b/wicket-user-guide/src/main/asciidoc/testingspring/testingspring_3.adoc
new file mode 100644
index 0000000..08ba48e
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/testingspring/testingspring_3.adoc
@@ -0,0 +1,4 @@
+
+
+
+With the configuration outlined above, no additional modifications are 
required to the test itself. It's going to turn green now. This way you can use 
exactly the same Spring context configuration that you'd use in your runtime 
environment for running your JUnit based integration tests as well.

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/urls.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/urls.adoc 
b/wicket-user-guide/src/main/asciidoc/urls.adoc
new file mode 100644
index 0000000..069c83b
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/urls.adoc
@@ -0,0 +1,7 @@
+
+Up to now we used component Link to move from a page to another and we have 
seen that it is quiet similar to a “click” event handler (see 
<<helloWorld.adoc#_wicket_links,paragraph 4.4>>). 
+
+However this component alone is not enough to build all possible kinds of 
links we may need in our pages. Therefore, Wicket offers other link components 
suited for those tasks which can not be accomplished with a basic Link. 
+
+Besides learning new link components, in this chapter we will also see how to 
customize the page URL generated by Wicket using the encoding facility provided 
by the framework and the page parameters that can be passed to a target page.
+

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/urls/urls_1.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/urls/urls_1.adoc 
b/wicket-user-guide/src/main/asciidoc/urls/urls_1.adoc
new file mode 100644
index 0000000..af25221
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/urls/urls_1.adoc
@@ -0,0 +1,115 @@
+
+
+
+A common practice in web development is to pass data to a page using query 
string parameters (like ?paramName1=paramValu1&paramName2=paramValue2...). 
Wicket offers a more flexible and object oriented way to do this with models 
(we will see them in the next chapter). However, even if we are using Wicket, 
we still need to use query string parameters to exchange data with other 
Internet-based services. Consider for example a classic confirmation page which 
is linked inside an email to let users confirm important actions like password 
changing or the subscription to a mailing list. This kind of page usually 
expects to receive a query string parameter containing the id of the action to 
confirm.
+
+Query string parameters can also be referred to as named parameters. In Wicket 
they are handled with class 
_org.apache.wicket.request.mapper.parameter.PageParameters_. Since named 
parameters are basically name-value pairs, PageParameters works in much the 
same way as Java Map providing two methods to create/modify a parameter 
(add(String name, Object value) and set(String name, Object value)),  one 
method to remove an existing parameter (remove(String name)) and one to 
retrieve the value of a given parameter (get(String name)) . Here is a snippet 
to illustrate the usage of PageParameters:
+
+[source,java]
+----
+PageParameters pageParameters = new PageParameters(); 
+//add a couple of parameters
+pageParameters.add("name", "John");
+pageParameters.add("age", 28);
+//retrieve the value of 'age' parameter
+pageParameters.get("age");
+----
+
+Now that we have seen how to work with page parameters, let's see how to use 
them with our pages.
+
+=== PageParameters and bookmarkable pages
+
+Base class Page comes with a constructor which takes as input a PageParameters 
instance. If we use this superclass constructor in our page, PageParameters 
will be used to build the page URL and it can be retrieved at a later time with 
the Page's getPageParameters() method.
+
+In the following example taken from the PageParametersExample project we have 
a home page with a link to a second page that uses a version of setResponsePage 
method that takes as input also a PageParameters to build the target page 
(named PageWithParameters). The code for the link and for the target page is 
the following:
+
+Link code:
+
+[source,java]
+----
+add(new Link("pageWithIndexParam") {
+
+       @Override
+       public void onClick() {
+               
+               PageParameters pageParameters = new PageParameters();
+               pageParameters.add("foo", "foo");
+               pageParameters.add("bar", "bar");
+                               
+               setResponsePage(PageWithParameters.class, pageParameters);
+       }
+                       
+});
+----
+
+Target page code:
+
+[source,java]
+----
+public class PageWithParameters extends WebPage {
+       //Override superclass constructor
+       public PageWithParameters(PageParameters parameters) {
+               super(parameters);
+       }
+ }
+----
+
+The code is quite straightforward and it’s more interesting to look at the 
URL generated for the target page:
+
+[source,html]
+----
+<app root>/PageParametersExample/wicket/bookmarkable/
+               org.wicketTutorial.PageWithParameters?foo=foo&bar=bar
+----
+
+At first glance the URL above could seem a little weird, except for the last 
part which contains the two named parameters used to build the target page.
+
+The reason for this “strange” URL is that, as we explained in paragraph 
8.3, when a page is instantiated using a constructor with no argument or using 
a constructor that accepts only a PageParameters, Wicket will try to generate a 
static URL for it, with no session-relative informations. This kind of URL is 
called bookmarkable because it can be saved by the users as a bookmark and 
accessed at a later time.
+
+A bookmarkable URL is composed by a fixed prefix (which by default is 
bookmarkable) and the qualified name of the page class 
(org.wicketTutorial.PageWithParameters in our example). Segment wicket is 
another fixed prefix added by default during URL generation. In paragraph 10.6 
we will see how to customize fixed prefixes with a custom implementation of 
IMapperContext interface.
+
+=== Indexed parameters
+
+Besides named parameters, Wicket also supports indexed parameters. These kinds 
of parameters are rendered as URL segments placed before named parameters. 
Let's consider for example the following URL:
+
+[source,html]
+----
+<application path>/foo/bar?1&baz=baz
+----
+
+The URL above contains two indexed parameters (foo and bar) and a query string 
consisting of the page id and a named parameter (baz). Just like named 
parameters also indexed parameters are handled by the PageParameters class. The 
methods provided by PageParameters for indexed parameters are set(int index, 
Object object) (to add/modify a parameter), remove(int index)(to remove a 
parameter) and get(int index) (to read a parameter).
+
+As their name suggests, indexed parameters are identified by a numeric index 
and they are rendered following the order in which they have been added to the 
PageParameters. The following is an example of indexed parameters:
+
+[source,java]
+----
+PageParameters pageParameters = new PageParameters(); 
+//add a couple of parameters
+pageParameters.set(0, "foo");
+pageParameters.set(1, "bar");
+//retrieve the value of the second parameter ("bar")
+pageParameters.get(1);
+----
+
+Project PageParametersExample comes also with a link to a page with both 
indexed parameters and a named parameter:
+
+[source,java]
+----
+add(new Link("pageWithNamedIndexParam") {
+
+       @Override
+       public void onClick() {
+                               
+               PageParameters pageParameters = new PageParameters();
+               pageParameters.set(0, "foo");
+               pageParameters.set(1, "bar");
+               pageParameters.add("baz", "baz");
+                               
+               setResponsePage(PageWithParameters.class, pageParameters);
+       }
+                       
+});
+----
+
+The URL generated for the linked page (PageWithParameters) is the one seen at 
the beginning of the paragraph.
+

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/urls/urls_2.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/urls/urls_2.adoc 
b/wicket-user-guide/src/main/asciidoc/urls/urls_2.adoc
new file mode 100644
index 0000000..a03ddb9
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/urls/urls_2.adoc
@@ -0,0 +1,11 @@
+
+
+
+A link to a bookmarkable page can be built with the link component 
_org.apache.wicket.markup.html.link.BookmarkablePageLink_:
+
+[source,java]
+----
+BookmarkablePageLink bpl=new BookmarkablePageLink(PageWithParameters.class, 
pageParameters);
+----
+
+The specific purpose of this component is to provide an anchor to a 
bookmarkable page, hence we don't have to implement any abstract method like we 
do with Link component.

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/urls/urls_3.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/urls/urls_3.adoc 
b/wicket-user-guide/src/main/asciidoc/urls/urls_3.adoc
new file mode 100644
index 0000000..ca52430
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/urls/urls_3.adoc
@@ -0,0 +1,75 @@
+
+
+
+Bookmarkable pages can be linked directly inside markup files without writing 
any Java code. Using <wicket:link> tag we ask Wicket to automatically add 
bookmarkable links for the anchors wrapped inside it. Here is an example of 
usage of <wicket:link> tag taken from the home page of the project 
BookmarkablePageAutoLink:
+
+[source,html]
+----
+<!DOCTYPE html>
+<html xmlns:wicket="http://wicket.apache.org";>
+       <head>
+               <meta charset="utf-8" />
+               <title>Apache Wicket Quickstart</title>
+       </head>
+       <body>          
+          <div id="bd">
+             <wicket:link>
+                       <a href="HomePage.html">HomePage</a><br/>
+                       <a 
href="anotherPackage/SubPackagePage.html">SubPackagePage</a> 
+             </wicket:link>
+          </div>               
+       </body>
+</html>
+----
+
+The key part of the markup above is the href attribute which must contain the 
package-relative path to a page. The home page is inside package 
org.wicketTutorial which in turns contains the sub package anotherPackage. This 
package hierarchy is reflected by the href attributes: in the first anchor we 
have a link to the home page itself while the second anchor points to page 
SubPackagePage which is placed into sub package anotherPackage. Absolute paths 
are supported as well and we can use them if we want to specify the full 
package of a given page. For example the link to SubPackagePage could have been 
written in the following (more verbose) way:
+
+[source,html]
+----
+<a href="/org/wicketTutorial/anotherPackage/SubPackagePage.html"> 
SubPackagePage</a>
+----
+
+If we take a look also at the markup of SubPackagePage we can see that it 
contains a link to the home page which uses the parent directory selector 
(relative path):
+
+[source,html]
+----
+<!DOCTYPE html>
+<html xmlns:wicket="http://wicket.apache.org";>
+       <head>
+               <meta charset="utf-8" />
+               <title>Apache Wicket Quickstart</title>
+       </head>
+       <body>          
+               <div id="bd">
+                       <wicket:link>
+                               <a href="../HomePage.html">HomePage</a><br/>
+                               <a 
href="SubPackagePage.html">SubPackagePage</a>                        
+                       </wicket:link>
+               </div>          
+       </body>
+</html>
+----
+
+Please note that any link to the current page (aka self link) is disabled. For 
example in the home page the self link is rendered like this:
+
+[source,html]
+----
+<span><em>HomePage</em></span>
+----
+
+The markup used to render disabled links can be customized using the markup 
settings (class org.apache.wicket.settings.MarkupSettings) available in the 
application class:
+
+[source,java]
+----
+@Override
+public void init()
+{
+       super.init();
+       //wrap disabled links with <b> tag
+       getMarkupSettings().setDefaultBeforeDisabledLink("<b>");
+       getMarkupSettings().setDefaultAfterDisabledLink("</b>");                
+}
+----
+
+The purpose of <wicket:link> tag is not limited to just simplifying the usage 
of bookmarkable pages. As we will see in chapter 13, this tag can also be 
adopted to manage web resources like pictures, CSS files, JavaScript files and 
so on.
+

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/urls/urls_4.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/urls/urls_4.adoc 
b/wicket-user-guide/src/main/asciidoc/urls/urls_4.adoc
new file mode 100644
index 0000000..c4c7f98
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/urls/urls_4.adoc
@@ -0,0 +1,58 @@
+
+
+
+Since Wicket uses plain HTML markup files as templates, we can place an anchor 
to an external page directly inside the markup file. When we need to 
dynamically generate external anchors, we can use link component 
_org.apache.wicket.markup.html.link.ExternalLink_. In order to build an 
external link we must specify the value of the href attribute using a model or 
a plain string. In the next snippet, given an instance of Person, we generate a 
Google search query for its full name:
+
+Html:
+
+[source,html]
+----
+<a wicket:id="externalSite">Search me on Google!</a>
+----
+
+Java code:
+
+[source,java]
+----
+Person person = new Person("John", "Smith"); 
+String fullName = person.getFullName();
+//Space characters must be replaced by character '+'
+String googleQuery = "http://www.google.com/search?q="; + fullName.replace(" ", 
"+");
+add(new ExternalLink("externalSite", googleQuery));
+----
+
+Generated anchor:
+
+[source,html]
+----
+<a href="http://www.google.com/search?q=John+Smith";>Search me on Google!</a>
+----
+
+If we need to specify a dynamic value for the text inside the anchor, we can 
pass it as an additional constructor parameter:
+
+Html:
+
+[source,html]
+----
+<a wicket:id="externalSite">Label goes here...</a>
+----
+
+Java code:
+
+[source,java]
+----
+Person person = new Person("John", "Smith"); 
+String fullName = person.getFullName();
+String googleQuery = "http://www.google.com/search?q="; + fullName.replace(" ", 
"+");
+String linkLabel = "Search '" + fullName + "' on Google.";
+
+add(new ExternalLink("externalSite", googleQuery, linkLabel));
+----
+
+Generated anchor:
+
+[source,html]
+----
+<a href="http://www.google.com/search?q=John+Smith";>Search 'John Smith' on 
Google.</a>
+----
+

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/urls/urls_5.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/urls/urls_5.adoc 
b/wicket-user-guide/src/main/asciidoc/urls/urls_5.adoc
new file mode 100644
index 0000000..262ebeb
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/urls/urls_5.adoc
@@ -0,0 +1,35 @@
+
+
+
+Component Link has a stateful nature, hence it cannot be used with stateless 
pages. To use links with these kinds of pages Wicket provides the convenience 
_org.apache.wicket.markup.html.link.StatelessLink_ component which is basically 
a subtype of Link with the stateless hint set to true. 
+
+Please keep in mind that Wicket generates a new instance of a stateless page 
also to serve stateless links, so the code inside the onClick() method can not 
depend on instance variables. To illustrate this potential issue let's consider 
the following code (from the project StatelessPage) where the value of the 
variable index is used inside onclick():
+
+[source,java]
+----
+public class StatelessPage extends WebPage {
+       private int index = 0;
+
+       public StatelessPage(PageParameters parameters) {
+               super(parameters);
+       }
+       
+       @Override
+       protected void onInitialize() {
+               super.onInitialize();
+               setStatelessHint(true);
+               
+               add(new StatelessLink("statelessLink") {
+
+                       @Override
+                       public void onClick() {
+                               //It will always print zero
+                               System.out.println(index++);
+                       }
+                       
+               });
+       }       
+}
+----
+
+The printed value will always be zero because a new instance of the page is 
used every time the user clicks on the statelessLink link.

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/urls/urls_6.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/urls/urls_6.adoc 
b/wicket-user-guide/src/main/asciidoc/urls/urls_6.adoc
new file mode 100644
index 0000000..2692bb9
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/urls/urls_6.adoc
@@ -0,0 +1,229 @@
+
+
+
+Having structured URLs in our site is a basic requirement if we want to build 
an efficient SEO strategy, but it also contributes to improve user experience 
with more intuitive URLs. Wicket provides two different ways to control URL 
generation. The first (and simplest) is to “mount” one or more pages to an 
arbitrary path, while a more powerful technique is to use custom 
implementations of IMapperContext and IPageParametersEncoder interfaces. In the 
next paragraphs we will learn both of these two techniques.
+
+=== Mounting a single page
+
+With Wicket we can mount a page to a given path in much the same way as we map 
a servlet filter to a desired path inside file web.xml (see 
<<helloWorld.adoc#_configuration_of_wicket_applications,paragraph 4.2>>). Using 
mountPage(String path, Class <T> pageClass) method of the WepApplication class 
we tell Wicket to respond with a new instance of pageClass whenever a user 
navigates to the given path. In the application class of the project 
MountedPagesExample we mount MountedPage to the  [/pageMount] path:
+
+[source,java]
+----
+@Override
+public void init()
+{
+       super.init();
+       mountPage("/pageMount", MountedPage.class);
+       //Other initialization code...
+}
+----
+
+The path provided to mountPage will be used to generate the URL for any page 
of the specified class:
+
+[source,java]
+----
+//it will return "/pageMount"
+RequestCycle.get().urlFor(MountedPage.class);
+----
+
+Under the hood the mountPage method mounts an instance of the request mapper 
_org.apache.wicket.request.mapper.MountedMapper_ configured for the given path:
+
+[source,java]
+----
+public final <T extends Page> void mountPage(final String path,final Class<T> 
pageClass) {
+       mount(new MountedMapper(path, pageClass));
+}
+----
+
+Request mappers and the Application's method mount have been introduced in the 
previous chapter 
(<<requestProcessing.adoc#_the_director_of_request_processing_requestcycle,paragraph
 9.3>>).
+
+=== Using parameter placeholders with mounted pages
+
+The path specified for mounted pages can contain dynamic segments which are 
populated with the values of the named parameters used to build the page. These 
segments are declared using special segments called parameter placeholders. 
Consider the path used in the following example:
+
+[source,java]
+----
+mountPage("/pageMount/${foo}/otherSegm", MountedPageWithPlaceholder.class);
+----
+
+The path used above is composed by three segments: the first and the last are 
fixed while the second will be replaced by the value of the named parameter foo 
that must be provided when the page  MountedPageWithPlaceholder is instantiated:
+
+Java code:
+
+[source,java]
+----
+PageParameters pageParameters = new PageParameters();
+pageParameters.add("foo", "foo");
+                               
+setResponsePage(MountedPageWithPlaceholder.class, pageParameters)
+----
+
+Generated URL:
+
+[source,html]
+----
+<Application path>/pageMount/foo/otherSegm
+----
+
+On the contrary if we manually insert an URL like '<web app 
path>/pageMount/bar/otherSegm', we can read value 'bar' retrieving the named 
parameter foo inside our page.
+
+Place holders can be declared as optional using the '1.' character in place of 
'$':
+
+[source,java]
+----
+mountPage("/pageMount/#{foo}/otherSegm", MountedPageOptionalPlaceholder.class);
+----
+
+If the named parameter for an optional placeholder is missing, the 
corresponding segment is removed from the final URL:
+
+Java code:
+
+[source,java]
+----
+PageParameters pageParameters = new PageParameters();
+setResponsePage(MountedPageWithPlaceholder.class, pageParameters);
+----
+
+Generated URL:
+
+[source,html]
+----
+<Application path>/pageMount/otherSegm
+----
+
+=== Mounting a package
+
+In addition to mounting a single page, Wicket allows to mount all of the pages 
inside a package to a given path. Method mountPackage(String path, Class<T> 
pageClass) of class WepApplication will mount every page inside pageClass's 
package to the specified path.
+
+The resulting URL for package-mounted pages will have the following structure:
+
+[source,html]
+----
+<Application path>/mountedPath/<PageClassName>[optional query string]
+----
+
+For example in the MountedPagesExample project we have mounted all pages 
inside the subpackage org.tutorialWicket.subPackage with this line of code:
+
+[source,java]
+----
+mountPackage("/mountPackage", StatefulPackageMount.class);
+----
+
+StatefulPackageMount is one of the pages placed into the desired package and 
its URL will be:
+
+[source,html]
+----
+<Application path>/mountPackage/StatefulPackageMount?1
+----
+
+Similarly to what is done by the mountPage method, the implementation of the 
mountPackage method mounts an instance of 
_org.apache.wicket.request.mapper.PackageMapper_ to the given path.
+
+=== Providing custom mapper context to request mappers
+
+Interface _org.apache.wicket.request.mapper.IMapperContext_ is used by request 
mappers to create new page instances and to retrieve static URL segments used 
to build and parse page URLs. Here is the list of these segments:
+
+* Namespace: it's the first URL segment of non-mounted pages. By default its 
value is wicket.
+* Identifier for non-bookmarkable URLs: it's the segment that identifies non 
bookmarkable pages. By default its value is page.
+* Identifier for bookmarkable URLs: it's the segment that identifies 
bookmarkable pages. By default its value is bookmarkable (as we have seen 
before in <<urls.adoc#_pageparameters,paragraph 10.1.1>>).
+* Identifier for resources: it's the segment that identifies Wicket resources. 
Its default value is resources. The topic of resource management will be 
covered in 
+<<_resource_management_with_wicket,chapter 16>>.
+
+IMapperContext provides a getter method for any segment listed above. By 
default Wicket uses class _org.apache.wicket.DefaultMapperContext_ as mapper 
context.
+
+Project CustomMapperContext is an example of customization of mapper context 
where we use index as identifier for non-bookmarkable pages and staticURL as 
identifier for bookmarkable pages. In this project, instead of implementing our 
mapper context from scratch, we used DefaultMapperContext as base class 
overriding just the two methods we need to achieve the desired result 
(getBookmarkableIdentifier() and getPageIdentifier()).  The final 
implementation is the following:
+
+[source,java]
+----
+public class CustomMapperContext extends DefaultMapperContext{
+
+       @Override
+       public String getBookmarkableIdentifier() {
+               return "staticURL";
+       }
+
+       @Override
+       public String getPageIdentifier() {
+               return "index";
+       }
+}
+----
+
+Now to use a custom mapper context in our application we must override the 
newMapperContext() method declared in the Application class and make it return 
our custom implementation of IMapperContext:
+
+[source,java]
+----
+@Override
+protected IMapperContext newMapperContext() {
+       return new CustomMapperContext();
+}
+----
+
+=== Controlling how page parameters are encoded with IPageParametersEncoder
+
+Some request mappers (like MountedMapper and PackageMapper) can delegate page 
parameters encoding/decoding to interface 
_org.apache.wicket.request.mapper.parameter.IPage ParametersEncoder_. This 
entity exposes two methods: encodePageParameters() and decodePageParameters(): 
the first  one is invoked to encode page parameters into an URL while the 
second one extracts parameters from the URL.
+
+Wicket comes with a built-in implementation of this interface which encodes 
named page parameters as URL segments using the following pattern: 
/paramName1/paramValue1/paramName2/param Value2...
+
+This built-in encoder is 
_org.apache.wicket.request.mapper.parameter.UrlPathPageParametersEncoder_ 
class. In the _PageParametersEncoderExample_ project we have manually mounted a 
_MountedMapper_ that takes as input also an _UrlPathPageParametersEncoder_:
+
+[source,java]
+----
+@Override
+public void init() {
+       super.init();
+       mount(new MountedMapper("/mountedPath", MountedPage.class, new 
UrlPathPageParametersEncoder()));
+}
+----
+
+The home page of the project contains just a link to the MountedPage web page. 
The code of the link and the resulting page URL are:
+
+Link code:
+
+[source,java]
+----
+add(new Link("mountedPage") {
+
+       @Override
+       public void onClick() {
+               
+               PageParameters pageParameters = new PageParameters();
+               pageParameters.add("foo", "foo");
+               pageParameters.add("bar", "bar");
+                       
+               setResponsePage(MountedPage.class, pageParameters);
+       }
+});
+----
+
+Generated URL:
+
+[source,html]
+----
+<Application path>/mountedPath/foo/foo/bar/bar?1
+----
+
+=== Encrypting page URLs
+
+Sometimes URLs are a double–edged sword for our site because they can expose 
too many details about the internal structure of our web application making it 
more vulnerable to malicious users.
+
+To avoid this kind of security threat we can use the _CryptoMapper_ request 
mapper which wraps an existing mapper and encrypts the original URL producing a 
single encrypted segment:
+
+image::../img/url-encrypted.png[]
+
+Typically, _CryptoMapper_ is registered into a Wicket application as the root 
request mapper wrapping the default one:
+
+[source,java]
+----
+@Override
+public void init() {
+       super.init();
+       setRootRequestMapper(new CryptoMapper(getRootRequestMapper(), this)); 
+       //pages and resources must be mounted after we have set CryptoMapper
+       mountPage("/foo/", HomePage.class);
+----
+
+As pointed out in the code above, pages and resources must be mounted after 
having set _CryptoMapper_ as root mapper, otherwise the mounted paths will not 
work.
+
+WARNING: By default _CryptoMapper_ encrypts page URLs with a cipher that might 
not be strong enough for production environment. Paragraph 
+<<_security_with_wicket,"Security with Wicket">> will provide a more detailed 
description of how Wicket encrypts page URLs and we will see how to use 
stronger ciphers.
+

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/urls/urls_7.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/urls/urls_7.adoc 
b/wicket-user-guide/src/main/asciidoc/urls/urls_7.adoc
new file mode 100644
index 0000000..74e8153
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/urls/urls_7.adoc
@@ -0,0 +1,6 @@
+
+
+
+Links and URLs are not trivial topics as they may seem and in Wicket they are 
strictly interconnected. Developers must choose the right trade-off between 
producing structured URLs and avoiding to make them verbose and vulnerable.
+
+In this chapter we have explored the tools provided by Wicket to control how 
URLs are generated. We have started with static URLs for bookmarkable pages and 
we have seen how to pass parameters to target pages with PageParameters. In the 
second part of the chapter we focused on mounting pages to a specific path and 
on controlling how parameters are encoded by Wicket. Finally, we have also seen 
how to encrypt URLs to prevent security vulnerabilities.

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/versioningCaching.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/versioningCaching.adoc 
b/wicket-user-guide/src/main/asciidoc/versioningCaching.adoc
new file mode 100644
index 0000000..e11358d
--- /dev/null
+++ b/wicket-user-guide/src/main/asciidoc/versioningCaching.adoc
@@ -0,0 +1,2 @@
+
+This chapter explains how Wicket manages page instances, underlining the 
difference between stateful and stateless pages. The chapter also introduces 
some advanced topics like Java Serialization and multi-level cache. However, to 
understand what you will read you are not required to be familiar with these 
concepts.

http://git-wip-us.apache.org/repos/asf/wicket/blob/533c2d36/wicket-user-guide/src/main/asciidoc/versioningCaching/versioningCaching_1.adoc
----------------------------------------------------------------------
diff --git 
a/wicket-user-guide/src/main/asciidoc/versioningCaching/versioningCaching_1.adoc
 
b/wicket-user-guide/src/main/asciidoc/versioningCaching/versioningCaching_1.adoc
new file mode 100644
index 0000000..97a0561
--- /dev/null
+++ 
b/wicket-user-guide/src/main/asciidoc/versioningCaching/versioningCaching_1.adoc
@@ -0,0 +1,10 @@
+
+
+
+Wicket pages can be divided into two categories: stateful and stateless pages. 
Stateful pages are those which rely on user session to store their internal 
state and to keep track of user interaction.
+On the contrary stateless pages are those which don't change their internal 
state during their lifecycle and they don't need to occupy space into user 
session. 
+
+From Wicket's point of view the biggest difference between these two types of 
page is that stateful pages are versioned, meaning that they will be saved into 
user session every time their internal state has changed. Wicket automatically 
assigns a session to the user the first time a stateful page is requested. Page 
versions are stored into user session using Java Serialization mechanism. 
+Stateless pages are never versioned and that's why they don't require a valid 
user session. If we want to know whether a page is stateless or not, we can 
call the isPageStateless() method of class Page.
+
+In order to build a stateless page we must comply with some rules to ensure 
that the page won't need to use user session. These rules are illustrated in 
paragraph 8.3 but before talking about stateless pages we must first understand 
how stateful pages are handled and why they are versioned.

Reply via email to