You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by da...@apache.org on 2016/11/18 15:15:46 UTC
[04/22] wicket git commit: Removes gdoc infrastructure,
adds asciidoctor files
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 \u201cHello world!\u201d
+
+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 \u201cdirector\u201d 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 (\u201cFirst label\u201d and \u201cSecond label\u201d), 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 \u201cclick\u201d 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¶mName2=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\u2019s 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 \u201cstrange\u201d 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 \u201cmount\u201d 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\u2013edged 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.