You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by ad...@apache.org on 2013/12/14 22:13:12 UTC
svn commit: r1550971 [11/15] - in /wicket/common/site/trunk/_site/guide: ./
gapi/ gapi/DefaultPackage/ gapi/spring/ guide/ guide/pages/
guide/src/docs/guide/chapter14/ guide/src/docs/guide/chapter15/
guide/src/docs/guide/chapter16/ guide/src/docs/guide...
Modified: wicket/common/site/trunk/_site/guide/guide/pages/chapter17_4.html
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/pages/chapter17_4.html?rev=1550971&r1=1550970&r2=1550971&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/pages/chapter17_4.html (original)
+++ wicket/common/site/trunk/_site/guide/guide/pages/chapter17_4.html Sat Dec 14 21:13:09 2013
@@ -157,7 +157,7 @@ function addJsClass() {
<h2 id="chapter17_4">18.4 Using an activity indicator</h2>
-<p class="paragraph"/>One of the things we must take care of when we use AJAX is to notify user when an AJAX request is already in progress. This is usually done displaying an animated picture as activity indicator while the AJAX request is running.<p class="paragraph"/>Wicket comes with a variant of components AjaxButton, AjaxLink and AjaxFallbackLink that display a default activity indicator during AJAX request processing. These components are respectively IndicatingAjaxButton, IndicatingAjaxLink and IndicatingAjaxFallbackLink.<p class="paragraph"/>The default activity indicator used in Wicket can be easily integrated in our components using behavior AjaxIndicatorAppender (available in package org.apache.wicket.extensions.ajax. markup.html) and implementing the interface IAjaxIndicatorAware (in package org.apache.wicket.ajax).<p class="paragraph"/>IAjaxIndicatorAware declares method getAjaxIndicatorMarkupId() which returns the id of the markup element used to display the activity
indicator. This id can be obtained from the AjaxIndicatorAppender behavior that has been added to the current component. The following code snippet summarizes the steps needed to integrate the default activity indicator with an ajaxified component:<p class="paragraph"/><div class="code"><pre>//1-Implement <span class="java-keyword">interface</span> IAjaxIndicatorAware
+<p class="paragraph"/>One of the things we must take care of when we use AJAX is to notify user when an AJAX request is already in progress. This is usually done displaying an animated picture as activity indicator while the AJAX request is running.<p class="paragraph"/>Wicket comes with a variant of components <code>AjaxButton</code>, <code>AjaxLink</code> and <code>AjaxFallbackLink</code> that display a default activity indicator during AJAX request processing. These components are respectively <code>IndicatingAjaxButton</code>, <code>IndicatingAjaxLink</code> and <code>IndicatingAjaxFallbackLink</code>.<p class="paragraph"/>The default activity indicator used in Wicket can be easily integrated in our components using behavior AjaxIndicatorAppender (available in package <code>org.apache.wicket.extensions.ajax.markup.html</code>) and implementing the interface <code>IAjaxIndicatorAware</code> (in package <code>org.apache.wicket.ajax</code>).<p class="paragraph"/><code>IAjaxIndicato
rAware</code> declares method <code>getAjaxIndicatorMarkupId()</code> which returns the id of the markup element used to display the activity indicator. This id can be obtained from the AjaxIndicatorAppender behavior that has been added to the current component. The following code snippet summarizes the steps needed to integrate the default activity indicator with an ajaxified component:<p class="paragraph"/><div class="code"><pre>//1-Implement <span class="java-keyword">interface</span> IAjaxIndicatorAware
<span class="java-keyword">public</span> class MyComponent <span class="java-keyword">extends</span> Component <span class="java-keyword">implements</span> IAjaxIndicatorAware {
//2-Instantiate an AjaxIndicatorAppender
<span class="java-keyword">private</span> AjaxIndicatorAppender indicatorAppender =
@@ -171,7 +171,7 @@ function addJsClass() {
<span class="java-keyword">return</span> indicatorAppender.getMarkupId();
}
//…
-}</pre></div><p class="paragraph"/>If we need to change the default picture used as activity indicator, we can override method getIndicatorUrl() of AjaxIndicatorAppender and return the URL to the desired picture.
+}</pre></div><p class="paragraph"/>If we need to change the default picture used as activity indicator, we can override method <code>getIndicatorUrl()</code> of <code>AjaxIndicatorAppender</code> and return the URL to the desired picture.
<div style="clear:both;margin-top:15px;"></div>
Modified: wicket/common/site/trunk/_site/guide/guide/pages/chapter17_5.html
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/pages/chapter17_5.html?rev=1550971&r1=1550970&r2=1550971&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/pages/chapter17_5.html (original)
+++ wicket/common/site/trunk/_site/guide/guide/pages/chapter17_5.html Sat Dec 14 21:13:09 2013
@@ -157,10 +157,10 @@ function addJsClass() {
<h2 id="chapter17_5">18.5 AJAX request attributes and call listeners</h2>
-<p class="paragraph"/>Starting from version 6.0 Wicket has introduced two entities which allow us to control how an AJAX request is generated on client side and to specify the custom JavaScript code we want to execute during request handling. These entities are class AjaxRequestAttributes and interface IAjaxCallListener, both placed in package org.apache.wicket.ajax.attributes.<p class="paragraph"/>AjaxRequestAttributes exposes the attributes used to generate the JavaScript call invoked on client side to start an AJAX request. Each attribute will be passed as a <a href="http://en.wikipedia.org/wiki/JSON" target="blank">JSON</a> parameter to the JavaScript function Wicket.Ajax.ajax which is responsible for sending the concrete AJAX request. Every JSON parameter is identified by a short name. Here is a partial list of the available parameters:<p class="paragraph"/><table class="wiki-table" cellpadding="0" cellspacing="0" border="0"><tr><th><strong class="bold">Short name</strong></th>
<th><strong class="bold">Description</strong></th><th><strong class="bold">Default value</strong></th></tr><tr class="table-odd"><td>u</td><td>The callback URL used to serve the AJAX request that will be sent.</td><td> </td></tr><tr class="table-even"><td>c</td><td>The id of the component that wants to start the AJAX call.</td><td> </td></tr><tr class="table-odd"><td>e</td><td>A list of event (click, change, etc...) that can trigger the AJAX call.</td><td>domready</td></tr><tr class="table-even"><td>m</td><td>The request method that must be used (GET or POST).</td><td>GET</td></tr><tr class="table-odd"><td>f</td><td>The id of the form that must be submitted with the AJAX call.</td><td> </td></tr><tr class="table-even"><td>mp</td><td>If the AJAX call involves the submission of a form, this flag indicates whether the data must be encoded using the encoding mode âmultipart/form-dataâ.</td><td>false</td></tr><tr class="table-odd"><td>sc</td><td>The input name of
the submitting component of the form</td><td> </td></tr><tr class="table-even"><td>async</td><td>A boolean parameter that indicates if the AJAX call is asynchronous (true) or not.</td><td>true</td></tr><tr class="table-odd"><td>wr</td><td>Specifies the type of data returned by the AJAX call (XML, HTML, JSON, etc...).</td><td>XML</td></tr><tr class="table-even"><td>bh, pre, bsh, ah, sh, fh, coh</td><td>This is a list of the listeners that are executed on client side (they are JavaScript scripts) during the lifecycle of an AJAX request. Each short name is the abbreviation of one of the methods defined in the interface IAjaxCallListener (see below).</td><td>An empty list</td></tr></table><p class="paragraph"/><blockquote class="note">
+<p class="paragraph"/>Starting from version 6.0 Wicket has introduced two entities which allow us to control how an AJAX request is generated on client side and to specify the custom JavaScript code we want to execute during request handling. These entities are class <code>AjaxRequestAttributes</code> and interface <code>IAjaxCallListener</code>, both placed in package <code>org.apache.wicket.ajax.attributes</code>.<p class="paragraph"/>AjaxRequestAttributes exposes the attributes used to generate the JavaScript call invoked on client side to start an AJAX request. Each attribute will be passed as a <a href="http://en.wikipedia.org/wiki/JSON" target="blank">JSON</a> parameter to the JavaScript function <code>Wicket.Ajax.ajax</code> which is responsible for sending the concrete AJAX request. Every JSON parameter is identified by a short name. Here is a partial list of the available parameters:<p class="paragraph"/><table class="wiki-table" cellpadding="0" cellspacing="0" border="0"><
tr><th><strong class="bold">Short name</strong></th><th><strong class="bold">Description</strong></th><th><strong class="bold">Default value</strong></th></tr><tr class="table-odd"><td>u</td><td>The callback URL used to serve the AJAX request that will be sent.</td><td> </td></tr><tr class="table-even"><td>c</td><td>The id of the component that wants to start the AJAX call.</td><td> </td></tr><tr class="table-odd"><td>e</td><td>A list of event (click, change, etc...) that can trigger the AJAX call.</td><td>domready</td></tr><tr class="table-even"><td>m</td><td>The request method that must be used (GET or POST).</td><td>GET</td></tr><tr class="table-odd"><td>f</td><td>The id of the form that must be submitted with the AJAX call.</td><td> </td></tr><tr class="table-even"><td>mp</td><td>If the AJAX call involves the submission of a form, this flag indicates whether the data must be encoded using the encoding mode âmultipart/form-dataâ.</td><td>false</td></tr><t
r class="table-odd"><td>sc</td><td>The input name of the submitting component of the form</td><td> </td></tr><tr class="table-even"><td>async</td><td>A boolean parameter that indicates if the AJAX call is asynchronous (true) or not.</td><td>true</td></tr><tr class="table-odd"><td>wr</td><td>Specifies the type of data returned by the AJAX call (XML, HTML, JSON, etc...).</td><td>XML</td></tr><tr class="table-even"><td>bh, pre, bsh, ah, sh, fh, coh</td><td>This is a list of the listeners that are executed on client side (they are JavaScript scripts) during the lifecycle of an AJAX request. Each short name is the abbreviation of one of the methods defined in the interface IAjaxCallListener (see below).</td><td>An empty list</td></tr></table><p class="paragraph"/><blockquote class="note">
A full list of the available request parameters as well as more details on the related JavaScript code can be found at <a href="https://cwiki.apache.org/confluence/" target="blank">https://cwiki.apache.org/confluence/ display/WICKET/Wicket+Ajax</a> display/WICKET/Wicket+Ajax .
-</blockquote><p class="paragraph"/>Parameters 'u' (callback URL) and 'c' (the id of the component) are generated by the AJAX behavior that will serve the AJAX call and they are not accessible through AjaxRequestAttributes.<p class="paragraph"/>Here is the final AJAX function generate for the behavior used in example project AjaxEventBehavior Example:<p class="paragraph"/><div class="code"><pre>Wicket.Ajax.ajax({<span class="java-quote">"u"</span>:<span class="java-quote">"./?0-1.IBehaviorListener.0-clickCounterLabel"</span>, <span class="java-quote">"e"</span>:<span class="java-quote">"click"</span>,
- <span class="java-quote">"c"</span>:<span class="java-quote">"clickCounterLabel1"</span>});</pre></div><p class="paragraph"/>Even if most of the times we will let Wicket generate request attributes for us, both AJAX components and behaviors give us the chance to modify them overriding their method updateAjaxAttributes (AjaxRequestAttributes attributes).<p class="paragraph"/>One of the attribute we may need to modify is the list of IAjaxCallListeners returned by method getAjaxCallListeners().<p class="paragraph"/>IAjaxCallListener defines a set of methods which return the JavaScript code (as a CharSequence) that must be executed on client side when the AJAX request handling reaches a given stage:
+</blockquote><p class="paragraph"/>Parameters 'u' (callback URL) and 'c' (the id of the component) are generated by the AJAX behavior that will serve the AJAX call and they are not accessible through <code>AjaxRequestAttributes</code>.<p class="paragraph"/>Here is the final AJAX function generate for the behavior used in example project <code>AjaxEventBehavior</code> Example:<p class="paragraph"/><div class="code"><pre>Wicket.Ajax.ajax({<span class="java-quote">"u"</span>:<span class="java-quote">"./?0-1.IBehaviorListener.0-clickCounterLabel"</span>, <span class="java-quote">"e"</span>:<span class="java-quote">"click"</span>,
+ <span class="java-quote">"c"</span>:<span class="java-quote">"clickCounterLabel1"</span>});</pre></div><p class="paragraph"/>Even if most of the times we will let Wicket generate request attributes for us, both AJAX components and behaviors give us the chance to modify them overriding their method <code>updateAjaxAttributes (AjaxRequestAttributes attributes)</code>.<p class="paragraph"/>One of the attribute we may need to modify is the list of <code>IAjaxCallListeners</code> returned by method <code>getAjaxCallListeners()</code>.<p class="paragraph"/><code>IAjaxCallListener</code> defines a set of methods which return the JavaScript code (as a <code>CharSequence</code>) that must be executed on client side when the AJAX request handling reaches a given stage:
<ul class="star">
<li><strong class="bold">getBeforeHandler(Component)</strong>: returns the JavaScript code that will be executed before any other handlers returned by IAjaxCallListener. The code is executed in a scope where it can use variable attrs, which is an array containing the JSON parameters passed to Wicket.Ajax.ajax.</li>
<li><strong class="bold">getPrecondition(Component)</strong>: returns the JavaScript code that will be used as precondition for the AJAX call. If the script returns false then neither the Ajax call nor the other handlers will be executed. The code is executed in a scope where it can use variable attrs, which is the same variable seen for getBeforeHandler.</li>
@@ -179,7 +179,7 @@ A full list of the available request par
</ul>
<li><strong class="bold">getFailureHandler(Component)</strong>: returns the JavaScript code that will be executed if the AJAX call has returned with a failure. The code is executed in a scope where it can use variable attrs, which is the same variable seen for getBeforeHandler.</li>
<li><strong class="bold">getCompleteHandler(Component)</strong>: returns the JavaScript that will be invoked after success or failure handler has been executed. The code is executed in a scope where it can use variables attrs, jqXHR and textStatus which are the same variables seen for getSuccessHandler.</li>
-</ul><p class="paragraph"/>In the next paragraph we will see an example of custom IAjaxCallListener designed to disable a component during AJAX request processing.
+</ul><p class="paragraph"/>In the next paragraph we will see an example of custom <code>IAjaxCallListener</code> designed to disable a component during AJAX request processing.
Modified: wicket/common/site/trunk/_site/guide/guide/pages/chapter17_6.html
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/pages/chapter17_6.html?rev=1550971&r1=1550970&r2=1550971&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/pages/chapter17_6.html (original)
+++ wicket/common/site/trunk/_site/guide/guide/pages/chapter17_6.html Sat Dec 14 21:13:09 2013
@@ -157,7 +157,7 @@ function addJsClass() {
<h2 id="chapter17_6">18.6 Creating custom AJAX call listener</h2>
-<p class="paragraph"/>Displaying an activity indicator is a nice way to notify user that an AJAX request is already running, but sometimes is not enough. In some situations we may need to completely disable a component during AJAX request processing, for example when we want to avoid that impatient users submit a form multiple times. In this paragraph we will see how to accomplish this goal building a custom and reusable IAjaxCallListener. The code used in this example is from project CustomAjaxListenerExample.<p class="paragraph"/><h3>What we want for our listener</h3><p class="paragraph"/>The listener should execute some JavaScript code to disable a given component when the component it is attached to is about to make an AJAX call. Then, when the AJAX request has been completed, the listener should bring back the disabled component to an active state.<p class="paragraph"/>When a component is disabled it must be clear to user that an AJAX request is running and that he/she must wai
t for it to complete. To achieve this result we want to disable a given component covering it with a semi-transparent overlay area with an activity indicator in the middle.<p class="paragraph"/>The final result will look like this:<p class="paragraph"/><img border="0" class="center" src="../img/custom-ajax-call-listener.png"></img><p class="paragraph"/><h3>How to implement the listener</h3><p class="paragraph"/>The listener will implement methods getBeforeHandler and getAfterHandler: the first will return the code needed to place an overlay <div> on the desired component while the second must remove this overlay when the AJAX call has completed.<p class="paragraph"/>To move and resize the overlay area we will use another module from <a href="http://jqueryui.com/position/" target="blank">JQueryUI library</a> that allows us to position DOM elements on our page relative to another element.<p class="paragraph"/>So our listener will depend on four static resources: the JQuery lib
rary, the position module of JQuery UI, the custom code used to move the overlay <div> and the picture used as activity indicator. Except for the activity indicator, all these resources must be added to page header section in order to be used.<p class="paragraph"/>Ajax call listeners can contribute to header section by simply implementing interface IComponentAwareHeaderContributor. Wicket provides adapter class AjaxCallListener that implements both IAjaxCallListener and IComponentAwareHeaderContributor. We will use this class as base class for our listener.<p class="paragraph"/><h3>JavaScript code</h3><p class="paragraph"/>Now that we know what to do on the Java side, let's have a look at the custom JavaScript code that must be returned by our listener (file moveHiderAndIndicator.js):<p class="paragraph"/><div class="code"><pre>DisableComponentListener = {
+<p class="paragraph"/>Displaying an activity indicator is a nice way to notify user that an AJAX request is already running, but sometimes is not enough. In some situations we may need to completely disable a component during AJAX request processing, for example when we want to avoid that impatient users submit a form multiple times. In this paragraph we will see how to accomplish this goal building a custom and reusable <code>IAjaxCallListener</code>. The code used in this example is from project <code>CustomAjaxListenerExample</code>.<p class="paragraph"/><h3>What we want for our listener</h3><p class="paragraph"/>The listener should execute some JavaScript code to disable a given component when the component it is attached to is about to make an AJAX call. Then, when the AJAX request has been completed, the listener should bring back the disabled component to an active state.<p class="paragraph"/>When a component is disabled it must be clear to user that an AJAX request is runnin
g and that he/she must wait for it to complete. To achieve this result we want to disable a given component covering it with a semi-transparent overlay area with an activity indicator in the middle.<p class="paragraph"/>The final result will look like this:<p class="paragraph"/><img border="0" class="center" src="../img/custom-ajax-call-listener.png"></img><p class="paragraph"/><h3>How to implement the listener</h3><p class="paragraph"/>The listener will implement methods <code>getBeforeHandler</code> and <code>getAfterHandler</code>: the first will return the code needed to place an overlay <div> on the desired component while the second must remove this overlay when the AJAX call has completed.<p class="paragraph"/>To move and resize the overlay area we will use another module from <a href="http://jqueryui.com/position/" target="blank">JQueryUI library</a> that allows us to position DOM elements on our page relative to another element.<p class="paragraph"/>So our listener
will depend on four static resources: the JQuery library, the position module of JQuery UI, the custom code used to move the overlay <div> and the picture used as activity indicator. Except for the activity indicator, all these resources must be added to page header section in order to be used.<p class="paragraph"/>Ajax call listeners can contribute to header section by simply implementing interface <code>IComponentAwareHeaderContributor</code>. Wicket provides adapter class <code>AjaxCallListener</code> that implements both <code>IAjaxCallListener</code> and <code>IComponentAwareHeaderContributor</code>. We will use this class as base class for our listener.<p class="paragraph"/><h3>JavaScript code</h3><p class="paragraph"/>Now that we know what to do on the Java side, let's have a look at the custom JavaScript code that must be returned by our listener (file moveHiderAndIndicator.js):<p class="paragraph"/><div class="code"><pre>DisableComponentListener = {
disableElement: function(elementId, activeIconUrl){
<span class="java-keyword">var</span> hiderId = elementId + <span class="java-quote">"-disable-layer"</span>;
<span class="java-keyword">var</span> indicatorId = elementId + <span class="java-quote">"-indicator-picture"</span>;<p class="paragraph"/> elementId = <span class="java-quote">"#"</span> + elementId;
@@ -208,7 +208,7 @@ function addJsClass() {
response.render(JavaScriptHeaderItem.forReference(jqueryUiPositionRef));
response.render(JavaScriptHeaderItem.forReference(customScriptReference) );
}
-}</pre></div><p class="paragraph"/>As you can see in the code above we have created a function (getIndicatorUrl) to retrieve the URL of the indicator picture. This was done in order to make the picture customizable by overriding this method.<p class="paragraph"/>Once we have our listener in place, we can finally use it in our example overwriting method updateAjaxAttributes of the AJAX button that submits the form:<p class="paragraph"/><div class="code"><pre>//…
+}</pre></div><p class="paragraph"/>As you can see in the code above we have created a function (<code>getIndicatorUrl</code>) to retrieve the URL of the indicator picture. This was done in order to make the picture customizable by overriding this method.<p class="paragraph"/>Once we have our listener in place, we can finally use it in our example overwriting method <code>updateAjaxAttributes</code> of the AJAX button that submits the form:<p class="paragraph"/><div class="code"><pre>//…
<span class="java-keyword">new</span> AjaxButton(<span class="java-quote">"ajaxButton"</span>){
@Override
<span class="java-keyword">protected</span> void updateAjaxAttributes(AjaxRequestAttributes attributes) {
@@ -216,7 +216,7 @@ function addJsClass() {
attributes.getAjaxCallListeners().add(<span class="java-keyword">new</span> DisableComponentListener(form));
}
}
-//...</pre></div><p class="paragraph"/><h3>Global listeners</h3><p class="paragraph"/>So far we have seen how to use an AJAX call listener to track the AJAX activity of a single component. In addition to these kinds of listeners, Wicket provides also global listeners which are triggered for any AJAX request sent from a page.<p class="paragraph"/>Global AJAX call events are handled with JavaScript. We can register a callback function for a specific event of the AJAX call lifecycle with function Wicket.Event.subscribe('<eventName>', <callback Function>). The first parameter of this function is the name of the event we want to handle. The possible names are:
+//...</pre></div><p class="paragraph"/><h3>Global listeners</h3><p class="paragraph"/>So far we have seen how to use an AJAX call listener to track the AJAX activity of a single component. In addition to these kinds of listeners, Wicket provides also global listeners which are triggered for any AJAX request sent from a page.<p class="paragraph"/>Global AJAX call events are handled with JavaScript. We can register a callback function for a specific event of the AJAX call lifecycle with function <code>Wicket.Event.subscribe('<eventName>', <callback Function>)</code>. The first parameter of this function is the name of the event we want to handle. The possible names are:
<ul class="star">
<li>'/ajax/call/before': called before any other event handler.</li>
<li>'/ajax/call/beforeSend': called just before the AJAX call.</li>
@@ -224,13 +224,13 @@ function addJsClass() {
<li>'/ajax/call/success': called if the AJAX call has successfully returned.</li>
<li>'/ajax/call/failure': called if the AJAX call has returned with a failure.</li>
<li>'/ajax/call/complete': called when the AJAX call has completed.</li>
-<li>'/dom/node/removing': called when a component is about to be removed via AJAX. This happens when component markup is updated via AJAX (i.e. the component itself or one of its containers has been added to AjaxRequestTarget)</li>
-<li>'/dom/node/added': called when a component has been added via AJAX. Just like '/dom/node/removing', this event is triggered when a component is added to AjaxRequest Target.</li>
-</ul><p class="paragraph"/>The callback function takes in input the following parameters: attrs, jqXHR, textStatus, jqEvent and errorThrown. The first three parameters are the same seen before with IAjaxCallListener while jqEvent is an event internally fired by Wicket. The last parameter errorThrown indicates if an error has occurred during the AJAX call.<p class="paragraph"/>To see a basic example of use of a global AJAX call listener, let's go back to our custom datepicker created in chapter 14. When we built it we didn't think about a possible use of the component with AJAX. When a complex component like our datepicker is refreshed via AJAX, the following two side effects can occur:
+<li>'/dom/node/removing': called when a component is about to be removed via AJAX. This happens when component markup is updated via AJAX (i.e. the component itself or one of its containers has been added to <code>AjaxRequestTarget</code>)</li>
+<li>'/dom/node/added': called when a component has been added via AJAX. Just like '/dom/node/removing', this event is triggered when a component is added to <code>AjaxRequestTarget</code>.</li>
+</ul><p class="paragraph"/>The callback function takes in input the following parameters: attrs, jqXHR, textStatus, jqEvent and errorThrown. The first three parameters are the same seen before with <code>IAjaxCallListener</code> while jqEvent is an event internally fired by Wicket. The last parameter errorThrown indicates if an error has occurred during the AJAX call.<p class="paragraph"/>To see a basic example of use of a global AJAX call listener, let's go back to our custom datepicker created in chapter 14. When we built it we didn't think about a possible use of the component with AJAX. When a complex component like our datepicker is refreshed via AJAX, the following two side effects can occur:
<ul class="star">
<li>After been refreshed, the component loses every JavaScript handler set on it. This is not a problem for our datepicker as it sets a new JQuery datepicker every time is rendered (inside method renderHead).</li>
<li>The markup previously created with JavaScript is not removed. For our datepicker this means that the icon used to open the calendar won't be removed while a new one will be added each time the component is refreshed.</li>
-</ul><p class="paragraph"/>To solve the second unwanted side effect we can register a global AJAX call listener that completely removes the datepicker functionality from our component before it is removed due to an AJAX refresh (which fires event '/dom/node/removing').<p class="paragraph"/>Project CustomDatepickerAjax contains a new version of our datepicker which adds to its JavaScript file JQDatePicker.js the code needed to register a callback function that gets rid of the JQuery datepicker before the component is removed from the DOM:<p class="paragraph"/><div class="code"><pre>Wicket.Event.subscribe('/dom/node/removing',
+</ul><p class="paragraph"/>To solve the second unwanted side effect we can register a global AJAX call listener that completely removes the datepicker functionality from our component before it is removed due to an AJAX refresh (which fires event '/dom/node/removing').<p class="paragraph"/>Project <code>CustomDatepickerAjax</code> contains a new version of our datepicker which adds to its JavaScript file JQDatePicker.js the code needed to register a callback function that gets rid of the JQuery datepicker before the component is removed from the DOM:<p class="paragraph"/><div class="code"><pre>Wicket.Event.subscribe('/dom/node/removing',
function(jqEvent, attributes, jqXHR, errorThrown, textStatus) {
<span class="java-keyword">var</span> componentId = '#' + attributes['id'];
<span class="java-keyword">if</span>($(componentId).datepicker !== undefined)
Modified: wicket/common/site/trunk/_site/guide/guide/pages/chapter18_1.html
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/pages/chapter18_1.html?rev=1550971&r1=1550970&r2=1550971&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/pages/chapter18_1.html (original)
+++ wicket/common/site/trunk/_site/guide/guide/pages/chapter18_1.html Sat Dec 14 21:13:09 2013
@@ -157,7 +157,7 @@ function addJsClass() {
<h2 id="chapter18_1">19.1 Integrating Wicket with EJB</h2>
-<p class="paragraph"/>WicketStuff provides a module called wicketstuff-javaee-inject that contains component instantiation listener JavaEEComponentInjector. If we register this listener in our application we can use standard EJB annotations to inject dependencies into our Wicket components.<p class="paragraph"/>To register a component instantiation listener in Wicket we must use Application's method getComponentInstantiationListeners which returns a typed collection of IComponent InstantiationListeners.<p class="paragraph"/>The following initialization code is taken from project EjbInjectionExample:<p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> class WicketApplication <span class="java-keyword">extends</span> WebApplication
+<p class="paragraph"/>WicketStuff provides a module called wicketstuff-javaee-inject that contains component instantiation listener <code>JavaEEComponentInjector</code>. If we register this listener in our application we can use standard EJB annotations to inject dependencies into our Wicket components.<p class="paragraph"/>To register a component instantiation listener in Wicket we must use <code>Application</code>'s method <code>getComponentInstantiationListeners</code> which returns a typed collection of <code>IComponentInstantiationListeners</code>.<p class="paragraph"/>The following initialization code is taken from project <code>EjbInjectionExample</code>:<p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> class WicketApplication <span class="java-keyword">extends</span> WebApplication
{
//Constructor...<p class="paragraph"/> @Override
<span class="java-keyword">public</span> void init()
Modified: wicket/common/site/trunk/_site/guide/guide/pages/chapter18_2.html
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/pages/chapter18_2.html?rev=1550971&r1=1550970&r2=1550971&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/pages/chapter18_2.html (original)
+++ wicket/common/site/trunk/_site/guide/guide/pages/chapter18_2.html Sat Dec 14 21:13:09 2013
@@ -157,7 +157,7 @@ function addJsClass() {
<h2 id="chapter18_2">19.2 Integrating Wicket with Spring</h2>
-<p class="paragraph"/>If we need to inject dependencies with Spring we can use listener org.apache.wicket.spring. injection.annot.SpringComponentInjector provided by module wicket-spring.<p class="paragraph"/>For the sake of simplicity in the example project SpringInjectionExample we have used Spring class AnnotationConfigApplicationContext to avoid any XML file and create a Spring context directly from code:<p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> class WicketApplication <span class="java-keyword">extends</span> WebApplication
+<p class="paragraph"/>If we need to inject dependencies with Spring we can use listener <code>org.apache.wicket.spring.injection.annot.SpringComponentInjector</code> provided by module wicket-spring.<p class="paragraph"/>For the sake of simplicity in the example project <code>SpringInjectionExample</code> we have used Spring class <code>AnnotationConfigApplicationContext</code> to avoid any XML file and create a Spring context directly from code:<p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> class WicketApplication <span class="java-keyword">extends</span> WebApplication
{
//Constructor...<p class="paragraph"/> @Override
<span class="java-keyword">public</span> void init()
@@ -167,7 +167,7 @@ function addJsClass() {
ctx.scan(<span class="java-quote">"org.wicketTutorial.ejbBean"</span>);
ctx.refresh();<p class="paragraph"/> getComponentInstantiationListeners().add(<span class="java-keyword">new</span> SpringComponentInjector(<span class="java-keyword">this</span>, ctx));
}
-}</pre></div><p class="paragraph"/>As we can see in the code above, the constructor of SpringComponentInjector takes in input also an instance of Spring context.<p class="paragraph"/>The injected object is the same used in the previous project EjbInjectionExample, it differs only for the greeting message:<p class="paragraph"/><div class="code"><pre>@ManagedBean
+}</pre></div><p class="paragraph"/>As we can see in the code above, the constructor of <code>SpringComponentInjector</code> takes in input also an instance of Spring context.<p class="paragraph"/>The injected object is the same used in the previous project <code>EjbInjectionExample</code>, it differs only for the greeting message:<p class="paragraph"/><div class="code"><pre>@ManagedBean
<span class="java-keyword">public</span> class EnterpriseMessage {
<span class="java-keyword">public</span> <span class="java-object">String</span> message = <span class="java-quote">"Welcome to the Spring world!"</span>;
}</pre></div><p class="paragraph"/>In the home page of the project the object is injected using Wicket annotation @SpringBean:<p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> class HomePage <span class="java-keyword">extends</span> WebPage {
@@ -176,7 +176,7 @@ function addJsClass() {
//getter and setter <span class="java-keyword">for</span> enterpriseMessage...<p class="paragraph"/> <span class="java-keyword">public</span> HomePage(<span class="java-keyword">final</span> PageParameters parameters) {
<span class="java-keyword">super</span>(parameters);<p class="paragraph"/> add(<span class="java-keyword">new</span> Label(<span class="java-quote">"message"</span>, enterpriseMessage.message));
}
-}</pre></div><p class="paragraph"/>By default @SpringBean searches into Spring context for a bean having the same type of the annotated field. If we want we can specify also the name of the bean to use as injected object and we can declare if the dependency is required or not. By default dependencies are required and if they can not be resolved to a compatible bean, Wicket will throw an IllegalStateException:<p class="paragraph"/><div class="code"><pre>//set the dependency as not required, i.e the field can be left <span class="java-keyword">null</span>
+}</pre></div><p class="paragraph"/>By default <code>SpringBean searches into Spring context for a bean having the same type of the annotated field. If we want we can specify also the name of the bean to use as injected object and we can declare if the dependency is required or not. By default dependencies are required and if they can not be resolved to a compatible bean, Wicket will throw an </code>IllegalStateException@:<p class="paragraph"/><div class="code"><pre>//set the dependency as not required, i.e the field can be left <span class="java-keyword">null</span>
@SpringBean(name=<span class="java-quote">"anotherName"</span>, required=<span class="java-keyword">false</span>)
<span class="java-keyword">private</span> EnterpriseMessage enterpriseMessage;</pre></div>
Modified: wicket/common/site/trunk/_site/guide/guide/pages/chapter18_4.html
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/pages/chapter18_4.html?rev=1550971&r1=1550970&r2=1550971&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/pages/chapter18_4.html (original)
+++ wicket/common/site/trunk/_site/guide/guide/pages/chapter18_4.html Sat Dec 14 21:13:09 2013
@@ -157,7 +157,7 @@ function addJsClass() {
<h2 id="chapter18_4">19.4 Summary</h2>
-<p class="paragraph"/>In this chapter we have seen how to integrate Wicket applications with Spring and with an EJB container. Module wicket-examples contains also an example of integration with Guice (see application class org.apache.wicket.examples.guice.GuiceApplication).<p class="paragraph"/>
+<p class="paragraph"/>In this chapter we have seen how to integrate Wicket applications with Spring and with an EJB container. Module wicket-examples contains also an example of integration with Guice (see application class <code>org.apache.wicket.examples.guice.GuiceApplication</code>).<p class="paragraph"/>
Modified: wicket/common/site/trunk/_site/guide/guide/pages/chapter19_1.html
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/pages/chapter19_1.html?rev=1550971&r1=1550970&r2=1550971&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/pages/chapter19_1.html (original)
+++ wicket/common/site/trunk/_site/guide/guide/pages/chapter19_1.html Sat Dec 14 21:13:09 2013
@@ -157,21 +157,21 @@ function addJsClass() {
<h2 id="chapter19_1">20.1 Authentication</h2>
-<p class="paragraph"/>The first step in implementing a security policy is assigning a trusted identity to our users, which means that we must authenticate them. Web applications usually adopt a form-based authentication with a login form that asks user for a unique username and the relative password:<p class="paragraph"/><img border="0" class="center" src="../img/wikipedia-login-form.png"></img><p class="paragraph"/>Wicket supports form-based authentication with session class AuthenticatedWebSession and application class AuthenticatedWebApplication, both placed inside package org.apache.wicket.authroles.authentication.<p class="paragraph"/><h3>AuthenticatedWebSession</h3><p class="paragraph"/>Class AuthenticatedWebSession comes with the following set of public methods to manage user authentication:
+<p class="paragraph"/>The first step in implementing a security policy is assigning a trusted identity to our users, which means that we must authenticate them. Web applications usually adopt a form-based authentication with a login form that asks user for a unique username and the relative password:<p class="paragraph"/><img border="0" class="center" src="../img/wikipedia-login-form.png"></img><p class="paragraph"/>Wicket supports form-based authentication with session class <code>AuthenticatedWebSession</code> and application class <code>AuthenticatedWebApplication</code>, both placed inside package <code>org.apache.wicket.authroles.authentication</code>.<p class="paragraph"/><h3>AuthenticatedWebSession</h3><p class="paragraph"/>Class AuthenticatedWebSession comes with the following set of public methods to manage user authentication:
<ul class="star">
-<li><strong class="bold">authenticate(String username, String password)</strong>: this is an abstract method that must be implemented by every subclass of AuthenticatedWebSession. It should contain the actual code that checks for user's identity. It returns a boolean value which is true if authentication has succeeded or false otherwise.</li>
+<li><strong class="bold">authenticate(String username, String password)</strong>: this is an abstract method that must be implemented by every subclass of <code>AuthenticatedWebSession</code>. It should contain the actual code that checks for user's identity. It returns a boolean value which is true if authentication has succeeded or false otherwise.</li>
<li><strong class="bold">signIn(String username, String password)</strong>: this method internally calls authenticate and set the flag signedIn to true if authentication succeeds.</li>
<li><strong class="bold">isSignedIn()</strong>:getter method for flag signedIn.</li>
<li><strong class="bold">signOut()</strong>: sets the flag signedIn to false.</li>
<li><strong class="bold">invalidate()</strong>: calls signOut and invalidates session.</li>
</ul><p class="paragraph"/><blockquote class="warning">
Remember that signOut does not discard any session-relative data. If we want to get rid of these data, we must invoke method invalidate instead of signOut.
-</blockquote><p class="paragraph"/>Another abstract method we must implement when we use AuthenticatedWebSession is getRoles which is inherited from parent class AbstractAuthenticatedWebSession. This method can be ignored for now as it will be discussed later when we will talk about role-based authorization.<p class="paragraph"/><h3>AuthenticatedWebApplication</h3><p class="paragraph"/>Class AuthenticatedWebApplication provides the following methods to support form-based authentication:
+</blockquote><p class="paragraph"/>Another abstract method we must implement when we use <code>AuthenticatedWebSession</code> is getRoles which is inherited from parent class <code>AbstractAuthenticatedWebSession</code>. This method can be ignored for now as it will be discussed later when we will talk about role-based authorization.<p class="paragraph"/><h3>AuthenticatedWebApplication</h3><p class="paragraph"/>Class AuthenticatedWebApplication provides the following methods to support form-based authentication:
<ul class="star">
-<li><strong class="bold">getWebSessionClass()</strong>: abstract method that returns the session class to use for this application. The returned class must be a subclass of AbstractAuthenticatedWeb Session.</li>
+<li><strong class="bold">getWebSessionClass()</strong>: abstract method that returns the session class to use for this application. The returned class must be a subclass of <code>AbstractAuthenticatedWebSession</code>.</li>
<li><strong class="bold">getSignInPageClass()</strong>: abstract method that returns the page to use as sign in page when a user must be authenticated.</li>
-<li><strong class="bold">restartResponseAtSignInPage()</strong>: forces the current response to restart at the sign in page. After we have used this method to redirect a user, we can make her/him return to the original page calling Componet's method continueToOriginalDestination().</li>
-</ul><p class="paragraph"/>The other methods implemented inside AuthenticatedWebApplication will be introduced when we will talk about authorizations.<p class="paragraph"/><h3>A basic example of authentication</h3><p class="paragraph"/>Project BasicAuthenticationExample is a basic example of form-based authentication implemented with classes AuthenticatedWebSession and AuthenticatedWebApplication.<p class="paragraph"/>The homepage of the project contains only a link to page AuthenticatedPage which can be accessed only if user is signed in. The code of AuthenticatedPage is this following:<p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> class AuthenticatedPage <span class="java-keyword">extends</span> WebPage {
+<li><strong class="bold">restartResponseAtSignInPage()</strong>: forces the current response to restart at the sign in page. After we have used this method to redirect a user, we can make her/him return to the original page calling <code>Componet</code>'s method <code>continueToOriginalDestination()</code>.</li>
+</ul><p class="paragraph"/>The other methods implemented inside <code>AuthenticatedWebApplication</code> will be introduced when we will talk about authorizations.<p class="paragraph"/><h3>A basic example of authentication</h3><p class="paragraph"/>Project <code>BasicAuthenticationExample</code> is a basic example of form-based authentication implemented with classes <code>AuthenticatedWebSession</code> and <code>AuthenticatedWebApplication</code>.<p class="paragraph"/>The homepage of the project contains only a link to page <code>AuthenticatedPage</code> which can be accessed only if user is signed in. The code of <code>AuthenticatedPage</code> is this following:<p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> class AuthenticatedPage <span class="java-keyword">extends</span> WebPage {
@Override
<span class="java-keyword">protected</span> void onConfigure() {
AuthenticatedWebApplication app = (AuthenticatedWebApplication)Application.get();
@@ -192,7 +192,7 @@ Remember that signOut does not discard a
}
});
}
-}</pre></div><p class="paragraph"/>Page AuthenticatedPage checks inside onConfigure if user is signed in and if not, it redirects her/him to the sign in page with method restartResponseAtSignInPage. The page contains also a link to the homepage and another link that signs out user.<p class="paragraph"/>The sign in page is implemented in class SignInPage and contains the form used to authenticate users:<p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> class SignInPage <span class="java-keyword">extends</span> WebPage {
+}</pre></div><p class="paragraph"/>Page <code>AuthenticatedPage</code> checks inside onConfigure if user is signed in and if not, it redirects her/him to the sign in page with method <code>restartResponseAtSignInPage</code>. The page contains also a link to the homepage and another link that signs out user.<p class="paragraph"/>The sign in page is implemented in class <code>SignInPage</code> and contains the form used to authenticate users:<p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> class SignInPage <span class="java-keyword">extends</span> WebPage {
<span class="java-keyword">private</span> <span class="java-object">String</span> username;
<span class="java-keyword">private</span> <span class="java-object">String</span> password;<p class="paragraph"/> @Override
<span class="java-keyword">protected</span> void onInitialize() {
@@ -208,7 +208,7 @@ Remember that signOut does not discard a
};<p class="paragraph"/> form.setDefaultModel(<span class="java-keyword">new</span> CompoundPropertyModel(<span class="java-keyword">this</span>));<p class="paragraph"/> form.add(<span class="java-keyword">new</span> TextField(<span class="java-quote">"username"</span>));
form.add(<span class="java-keyword">new</span> PasswordTextField(<span class="java-quote">"password"</span>));<p class="paragraph"/> add(form);
}
-}</pre></div><p class="paragraph"/>The form is responsible for handling user authentication inside its method onSubmit. The username and password are passed to AuthenticatedWebSession's method signIn(username, password) and if authentication succeeds, the user is redirected to the original page with method continueToOriginalDestination.<p class="paragraph"/>The session class and the application class used in the project are reported here:<p class="paragraph"/><strong class="bold">Session class:</strong><p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> class BasicAuthenticationSession <span class="java-keyword">extends</span> AuthenticatedWebSession {<p class="paragraph"/> <span class="java-keyword">public</span> BasicAuthenticationSession(Request request) {
+}</pre></div><p class="paragraph"/>The form is responsible for handling user authentication inside its method onSubmit. The username and password are passed to <code>AuthenticatedWebSession</code>'s method <code>signIn(username, password)</code> and if authentication succeeds, the user is redirected to the original page with method <code>continueToOriginalDestination</code>.<p class="paragraph"/>The session class and the application class used in the project are reported here:<p class="paragraph"/><strong class="bold">Session class:</strong><p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> class BasicAuthenticationSession <span class="java-keyword">extends</span> AuthenticatedWebSession {<p class="paragraph"/> <span class="java-keyword">public</span> BasicAuthenticationSession(Request request) {
<span class="java-keyword">super</span>(request);
}<p class="paragraph"/> @Override
<span class="java-keyword">public</span> <span class="java-object">boolean</span> authenticate(<span class="java-object">String</span> username, <span class="java-object">String</span> password) {
@@ -229,8 +229,8 @@ Remember that signOut does not discard a
<span class="java-keyword">protected</span> <span class="java-object">Class</span><? <span class="java-keyword">extends</span> WebPage> getSignInPageClass() {
<span class="java-keyword">return</span> SignInPage.class;
}
-}</pre></div><p class="paragraph"/>The authentication logic inside authenticate has been kept quite trivial in order to make the code as clean as possible. Please note also that session class must have a constructor that accepts an instance of class Request.<p class="paragraph"/><h3>Redirecting user to an intermediate page</h3><p class="paragraph"/>Method restartResponseAtSignInPage is an example of redirecting user to an intermediate page before allowing him to access to the requested page. This method internally throws exception org.apache.wicket.RestartResponseAtInterceptPageException which saves the URL of the requested page into session metadata and then redirects user to the page passed as constructor parameter (the sign in page).<p class="paragraph"/>Component's method redirectToInterceptPage(Page) works in much the same way as restartResponseAtSignInPage but it allows us to specify which page to use as intermediate page:<p class="paragraph"/><code>redirectToInterceptP
age(intermediatePage);</code><p class="paragraph"/><blockquote class="note">
-Since both restartResponseAtSignInPage and redirectToIntercept Page internally throw an exception, the code placed after them will not be executed.
+}</pre></div><p class="paragraph"/>The authentication logic inside authenticate has been kept quite trivial in order to make the code as clean as possible. Please note also that session class must have a constructor that accepts an instance of class <code>Request</code>.<p class="paragraph"/><h3>Redirecting user to an intermediate page</h3><p class="paragraph"/>Method <code>restartResponseAtSignInPage</code> is an example of redirecting user to an intermediate page before allowing him to access to the requested page. This method internally throws exception <code>org.apache.wicket.RestartResponseAtInterceptPageException</code> which saves the URL of the requested page into session metadata and then redirects user to the page passed as constructor parameter (the sign in page).<p class="paragraph"/>Component's method <code>redirectToInterceptPage(Page)</code> works in much the same way as <code>restartResponseAtSignInPage</code> but it allows us to specify which page to use as int
ermediate page:<p class="paragraph"/><code>redirectToInterceptPage(intermediatePage);</code><p class="paragraph"/><blockquote class="note">
+Since both <code>restartResponseAtSignInPage</code> and <code>redirectToInterceptPage</code> internally throw an exception, the code placed after them will not be executed.
</blockquote>
Modified: wicket/common/site/trunk/_site/guide/guide/pages/chapter19_2.html
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/pages/chapter19_2.html?rev=1550971&r1=1550970&r2=1550971&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/pages/chapter19_2.html (original)
+++ wicket/common/site/trunk/_site/guide/guide/pages/chapter19_2.html Sat Dec 14 21:13:09 2013
@@ -157,7 +157,7 @@ function addJsClass() {
<h2 id="chapter19_2">20.2 Authorizations</h2>
-<p class="paragraph"/>The authorization support provided by Wicket is built around the concept of authorization strategy which is represented by interface IAuthorizationStrategy (in package org.apache.wicket .authorization):<p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> <span class="java-keyword">interface</span> IAuthorizationStrategy
+<p class="paragraph"/>The authorization support provided by Wicket is built around the concept of authorization strategy which is represented by interface <code>IAuthorizationStrategy</code> (in package <code>org.apache.wicket.authorization</code>):<p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> <span class="java-keyword">interface</span> IAuthorizationStrategy
{
//<span class="java-keyword">interface</span> methods
<T <span class="java-keyword">extends</span> IRequestableComponent> <span class="java-object">boolean</span> isInstantiationAuthorized(<span class="java-object">Class</span><T> componentClass);
@@ -179,7 +179,7 @@ function addJsClass() {
<ul class="star">
<li>isInstantiationAuthorized checks if user is allowed to instantiate a given component.</li>
<li>isActionAuthorized checks if user is authorized to perform a given action on a component's instance. The standard actions checked by this method are defined into class Action and are Action.ENABLE and Action.RENDER.</li>
-</ul><p class="paragraph"/>Inside IAuthorizationStrategy we can also find a default implementation of the interface (called ALLOW_ALL) that allows everyone to instantiate every component and perform every possible action on it. This is the default strategy adopted by class Application.<p class="paragraph"/>To change the authorization strategy in use we must register the desired implementation into security settings (interface ISecuritySettings) during initialization phase with method setAuthorization Strategy:<p class="paragraph"/><div class="code"><pre>//Application class code…
+</ul><p class="paragraph"/>Inside <code>IAuthorizationStrategy</code> we can also find a default implementation of the interface (called ALLOW_ALL) that allows everyone to instantiate every component and perform every possible action on it. This is the default strategy adopted by class <code>Application</code>.<p class="paragraph"/>To change the authorization strategy in use we must register the desired implementation into security settings (interface <code>ISecuritySettings</code>) during initialization phase with method setAuthorization Strategy:<p class="paragraph"/><div class="code"><pre>//Application class code…
@Override
<span class="java-keyword">public</span> void init()
{
@@ -187,14 +187,14 @@ function addJsClass() {
getSecuritySettings().
setAuthorizationStrategy(myAuthorizationStrategy);
}
-//...</pre></div><p class="paragraph"/>If we want to combine the action of two or more authorization strategies we can chain them with strategy CompoundAuthorizationStrategy which implements composite patter for authorization strategies.<p class="paragraph"/>Most of the times we won't need to implement an IAuthorizationStrategy from scratch as Wicket already comes with a set of built-in strategies. In the next paragraphs we will see some of these strategies that can be used to implement an effective and flexible security policy.<p class="paragraph"/><h3>SimplePageAuthorizationStrategy</h3><p class="paragraph"/>Abstract class SimplePageAuthorizationStrategy (in package org.apache.wicket.authorization.strategies.page) is a strategy that checks user authorizations calling abstract method isAuthorized only for those pages that are subclasses of a given supertype. If isAuthorized returns false, the user is redirected to the sign in page specified as second constructor parameter:<p class=
"paragraph"/><div class="code"><pre>SimplePageAuthorizationStrategy authorizationStrategy = <span class="java-keyword">new</span> SimplePageAuthorizationStrategy(
+//...</pre></div><p class="paragraph"/>If we want to combine the action of two or more authorization strategies we can chain them with strategy <code>CompoundAuthorizationStrategy</code> which implements composite patter for authorization strategies.<p class="paragraph"/>Most of the times we won't need to implement an <code>IAuthorizationStrategy</code> from scratch as Wicket already comes with a set of built-in strategies. In the next paragraphs we will see some of these strategies that can be used to implement an effective and flexible security policy.<p class="paragraph"/><h3>SimplePageAuthorizationStrategy</h3><p class="paragraph"/>Abstract class SimplePageAuthorizationStrategy (in package <code>org.apache.wicket.authorization.strategies.page</code>) is a strategy that checks user authorizations calling abstract method <code>isAuthorized</code> only for those pages that are subclasses of a given supertype. If <code>isAuthorized</code> returns false, the user is redirected to the
sign in page specified as second constructor parameter:<p class="paragraph"/><div class="code"><pre>SimplePageAuthorizationStrategy authorizationStrategy = <span class="java-keyword">new</span> SimplePageAuthorizationStrategy(
PageClassToCheck.class, SignInPage.class)
{
<span class="java-keyword">protected</span> <span class="java-object">boolean</span> isAuthorized()
{
//Authentication code…
}
-};</pre></div><p class="paragraph"/>By default SimplePageAuthorizationStrategy checks for permissions only on pages. If we want to change this behavior and check also other kinds of components, we must override method isActionAuthorized and implement our custom logic inside it.<p class="paragraph"/><h3>Role-based strategies</h3><p class="paragraph"/>At the end of paragraph 18.1.1 we have introduced AbstractAuthenticatedWebSession's method getRoles which is provided to support role-based authorization returning the set of roles granted to the current user.<p class="paragraph"/>In Wicket roles are simple strings like âBASIC_USERâ or âADMINâ (they don't need to be capitalized) and they are handled with class org.apache.wicket.authroles.authorization.strategies. role.Roles. This class extends standard HashSet collection adding some functionalities to check whether the set contains one or more roles. Class Roles already defines roles Roles.USER and Roles.ADMIN.<p
class="paragraph"/>The session class in the following example returns a custom âSIGNED_INâ role for every authenticated user and it adds an Roles.ADMIN role if username is equal to superuser:<p class="paragraph"/><div class="code"><pre>class BasicAuthenticationRolesSession <span class="java-keyword">extends</span> AuthenticatedWebSession {
+};</pre></div><p class="paragraph"/>By default <code>SimplePageAuthorizationStrategy</code> checks for permissions only on pages. If we want to change this behavior and check also other kinds of components, we must override method <code>isActionAuthorized</code> and implement our custom logic inside it.<p class="paragraph"/><h3>Role-based strategies</h3><p class="paragraph"/>At the end of paragraph 18.1.1 we have introduced AbstractAuthenticatedWebSession's method getRoles which is provided to support role-based authorization returning the set of roles granted to the current user.<p class="paragraph"/>In Wicket roles are simple strings like âBASIC_USERâ or âADMINâ (they don't need to be capitalized) and they are handled with class <code>org.apache.wicket.authroles.authorization.strategies.role.Roles</code>. This class extends standard HashSet collection adding some functionalities to check whether the set contains one or more roles. Class <code>Roles</code>
already defines roles Roles.USER and Roles.ADMIN.<p class="paragraph"/>The session class in the following example returns a custom âSIGNED_INâ role for every authenticated user and it adds an Roles.ADMIN role if username is equal to superuser:<p class="paragraph"/><div class="code"><pre>class BasicAuthenticationRolesSession <span class="java-keyword">extends</span> AuthenticatedWebSession {
<span class="java-keyword">private</span> <span class="java-object">String</span> userName;<p class="paragraph"/> <span class="java-keyword">public</span> BasicAuthenticationRolesSession(Request request) {
<span class="java-keyword">super</span>(request);
}<p class="paragraph"/> @Override
@@ -207,9 +207,9 @@ function addJsClass() {
resultRoles.add(<span class="java-quote">"SIGNED_IN"</span>);<p class="paragraph"/> <span class="java-keyword">if</span>(userName.equals(<span class="java-quote">"superuser"</span>))
resultRoles.add(Roles.ADMIN);<p class="paragraph"/> <span class="java-keyword">return</span> resultRoles;
}
-}</pre></div><p class="paragraph"/>Roles can be adopted to apply security restrictions on our pages and components. This can be done using one of the two built-in authorization strategies that extend super class AbstractRole AuthorizationStrategyWicket: MetaDataRoleAuthorizationStrategy and Annotations RoleAuthorizationStrategy<p class="paragraph"/>The difference between these two strategies is that MetaDataRoleAuthorizationStrategy handles role-based authorizations with Wicket metadata while AnnotationsRoleAuthorization-Strategy uses Java annotations.<p class="paragraph"/><blockquote class="note">
-Application class AuthenticatedWebApplication already sets MetaData RoleAuthorizationStrategy and AnnotationsRoleAuthorization Strategy as its own authorization strategies (it uses a compound strategy as we will see in paragraph 18.2.4).<p class="paragraph"/>The code that we will see in the next examples is for illustrative purpose only. If our application class inherits from AuthenticatedWebApplication we won't need to configure anything to use these two strategies.
-</blockquote><p class="paragraph"/><h4>Using roles with metadata</h4><p class="paragraph"/>Strategy MetaDataRoleAuthorizationStrategy uses application and components metadata to implement role-based authorizations. The class defines a set of static methods authorize that can be used to specify which roles are allowed to instantiate a component and which roles can perform a given action on a component.<p class="paragraph"/>The following code snippet reports both application and session classes from project MetaDataRolesStrategyExample and illustrates how to use MetaDataRoleAuthorizationStrategy to allow access to a given page (AdminOnlyPage) only to ADMIN role:<p class="paragraph"/><strong class="bold">Application class:</strong><p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> class WicketApplication <span class="java-keyword">extends</span> AuthenticatedWebApplication{
+}</pre></div><p class="paragraph"/>Roles can be adopted to apply security restrictions on our pages and components. This can be done using one of the two built-in authorization strategies that extend super class <code>AbstractRoleAuthorizationStrategyWicket</code>: <code>MetaDataRoleAuthorizationStrategy</code> and <code>AnnotationsRoleAuthorizationStrategy</code><p class="paragraph"/>The difference between these two strategies is that <code>MetaDataRoleAuthorizationStrategy</code> handles role-based authorizations with Wicket metadata while <code>AnnotationsRoleAuthorizationStrategy</code> uses Java annotations.<p class="paragraph"/><blockquote class="note">
+Application class <code>AuthenticatedWebApplication</code> already sets <code>MetaDataRoleAuthorizationStrategy</code> and <code>AnnotationsRoleAuthorizationStrategy</code> as its own authorization strategies (it uses a compound strategy as we will see in paragraph 18.2.4).<p class="paragraph"/>The code that we will see in the next examples is for illustrative purpose only. If our application class inherits from <code>AuthenticatedWebApplication</code> we won't need to configure anything to use these two strategies.
+</blockquote><p class="paragraph"/><h4>Using roles with metadata</h4><p class="paragraph"/>Strategy <code>MetaDataRoleAuthorizationStrategy</code> uses application and components metadata to implement role-based authorizations. The class defines a set of static methods authorize that can be used to specify which roles are allowed to instantiate a component and which roles can perform a given action on a component.<p class="paragraph"/>The following code snippet reports both application and session classes from project <code>MetaDataRolesStrategyExample</code> and illustrates how to use <code>MetaDataRoleAuthorizationStrategy</code> to allow access to a given page (AdminOnlyPage) only to ADMIN role:<p class="paragraph"/><strong class="bold">Application class:</strong><p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> class WicketApplication <span class="java-keyword">extends</span> AuthenticatedWebApplication{
@Override
<span class="java-keyword">public</span> <span class="java-object">Class</span><? <span class="java-keyword">extends</span> WebPage> getHomePage(){
<span class="java-keyword">return</span> HomePage.class;
@@ -244,19 +244,19 @@ Application class AuthenticatedWebApplic
<span class="java-keyword">super</span>.signOut();
username = <span class="java-keyword">null</span>;
}
-}</pre></div><p class="paragraph"/>The code that instantiates MetaDataRoleAuthorizationStrategy and set it as application's strategy is inside application class method init.<p class="paragraph"/>Any subclass of AbstractRoleAuthorizationStrategyWicket needs an implementation of interface IRoleCheckingStrategy to be instantiated. For this purpose in the code above we used the application class itself because its base class AuthenticatedWebApplication already implements interface IRoleCheckingStrategy. By default AuthenticatedWebApplication checks for authorizations using the roles returned by the current AbstractAuthenticated WebSession. As final step inside init we grant the access to page AdminOnlyPage to ADMIN role calling method authorize.<p class="paragraph"/>The code from session class has three interesting methods. The first is authenticate which considers as valid credentials every pair of username and password having the same value. The second notable method is getRoles
which returns role SIGNED_IN if user is authenticated and it adds role ADMIN if username is equal to superuser. Finally, we have method signOut which has been overridden in order to clean the username field used internally to generate roles.<p class="paragraph"/>Now if we run the project and we try to access to AdminOnlyPage from the home page without having the ADMIN role, we will be redirected to the default access-denied page used by Wicket:<p class="paragraph"/><img border="0" class="center" src="../img/authorization-access-denied.png"></img><p class="paragraph"/>The access-denied page can be customized using method setAccessDeniedPage(Class<? extends Page>) of setting interface IApplicationSettings:<p class="paragraph"/><div class="code"><pre>//Application class code…
+}</pre></div><p class="paragraph"/>The code that instantiates <code>MetaDataRoleAuthorizationStrategy</code> and set it as application's strategy is inside application class method init.<p class="paragraph"/>Any subclass of <code>AbstractRoleAuthorizationStrategyWicket</code> needs an implementation of interface <code>IRoleCheckingStrategy</code> to be instantiated. For this purpose in the code above we used the application class itself because its base class <code>AuthenticatedWebApplication</code> already implements interface <code>IRoleCheckingStrategy</code>. By default <code>AuthenticatedWebApplication</code> checks for authorizations using the roles returned by the current <code>AbstractAuthenticatedWebSession</code>. As final step inside init we grant the access to page <code>AdminOnlyPage</code> to ADMIN role calling method authorize.<p class="paragraph"/>The code from session class has three interesting methods. The first is authenticate which considers as valid creden
tials every pair of username and password having the same value. The second notable method is getRoles which returns role SIGNED_IN if user is authenticated and it adds role ADMIN if username is equal to superuser. Finally, we have method signOut which has been overridden in order to clean the username field used internally to generate roles.<p class="paragraph"/>Now if we run the project and we try to access to <code>AdminOnlyPage</code> from the home page without having the ADMIN role, we will be redirected to the default access-denied page used by Wicket:<p class="paragraph"/><img border="0" class="center" src="../img/authorization-access-denied.png"></img><p class="paragraph"/>The access-denied page can be customized using method <code>setAccessDeniedPage(Class<? extends Page>)</code> of setting interface <code>IApplicationSettings</code>:<p class="paragraph"/><div class="code"><pre>//Application class code…
@Override
<span class="java-keyword">public</span> void init(){
getApplicationSettings().setAccessDeniedPage(
MyCustomAccessDeniedPage.class);
- }</pre></div><p class="paragraph"/>Just like custom âPage expiredâ page (see chapter 6.2.5), also custom âAccess deniedâ page must be bookmarkable.<p class="paragraph"/><h4>Using roles with annotations</h4><p class="paragraph"/>Strategy AnnotationsRoleAuthorizationStrategy relies on two built-in annotations to handle role-based authorizations. These annotations are AuthorizeInstantiation and Authorize Action. As their names suggest the first annotation specifies which roles are allowed to instantiate the annotated component while the second must be used to indicate which roles are allowed to perform a specific action on the annotated component.<p class="paragraph"/>In the following example we use annotations to make a page accessible only to signed-in users and to enable it only if user has the ADMIN role:<p class="paragraph"/><div class="code"><pre>@AuthorizeInstantiation(<span class="java-quote">"SIGNED_IN"</span>)
+ }</pre></div><p class="paragraph"/>Just like custom âPage expiredâ page (see chapter 6.2.5), also custom âAccess deniedâ page must be bookmarkable.<p class="paragraph"/><h4>Using roles with annotations</h4><p class="paragraph"/>Strategy <code>AnnotationsRoleAuthorizationStrategy</code> relies on two built-in annotations to handle role-based authorizations. These annotations are <code>AuthorizeInstantiation</code> and <code>AuthorizeAction</code>. As their names suggest the first annotation specifies which roles are allowed to instantiate the annotated component while the second must be used to indicate which roles are allowed to perform a specific action on the annotated component.<p class="paragraph"/>In the following example we use annotations to make a page accessible only to signed-in users and to enable it only if user has the ADMIN role:<p class="paragraph"/><div class="code"><pre>@AuthorizeInstantiation(<span class="java-quote">"SIGNED_IN"</spa
n>)
@AuthorizeAction(action = <span class="java-quote">"ENABLE"</span>, roles = {<span class="java-quote">"ADMIN"</span>})
<span class="java-keyword">public</span> class MyPage <span class="java-keyword">extends</span> WebPage {
//Page class code…
-}</pre></div><p class="paragraph"/>Remember that when a component is not enabled, user can render it but he can neither click on its links nor interact with its forms.<p class="paragraph"/>Example project AnnotationsRolesStrategyExample is a revisited version of MetaDataRolesStrategy Example where we use AnnotationsRoleAuthorizationStrategy as authorization strategy. To ensure that page AdminOnlyPage is accessible only to ADMIN role we have used the following annotation:<p class="paragraph"/><div class="code"><pre>@AuthorizeInstantiation(<span class="java-quote">"ADMIN"</span>)
+}</pre></div><p class="paragraph"/>Remember that when a component is not enabled, user can render it but he can neither click on its links nor interact with its forms.<p class="paragraph"/>Example project <code>AnnotationsRolesStrategyExample</code> is a revisited version of <code>MetaDataRolesStrategyExample</code> where we use <code>AnnotationsRoleAuthorizationStrategy</code> as authorization strategy. To ensure that page <code>AdminOnlyPage</code> is accessible only to ADMIN role we have used the following annotation:<p class="paragraph"/><div class="code"><pre>@AuthorizeInstantiation(<span class="java-quote">"ADMIN"</span>)
<span class="java-keyword">public</span> class AdminOnlyPage <span class="java-keyword">extends</span> WebPage {
//Page class code…
-}</pre></div><p class="paragraph"/><h3>Catching an unauthorized component instantiation</h3><p class="paragraph"/>Interface IUnauthorizedComponentInstantiationListener (in package org.apache.wicket.authorization) is provided to give the chance to handle the case in which a user tries to instantiate a component without having the permissions to do it. The method defined inside this interface is onUnauthorizedInstantiation(Component) and it is executed whenever a user attempts to execute an unauthorized instantiation.<p class="paragraph"/>This listener must be registered into application's security settings with method setUnauthorized ComponentInstantiationListener defined by setting interface ISecuritySettings. In the following code snippet we register a listener that redirect user to a warning page if he tries to do a not-allowed instantiation:<p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</span> class WicketApplication <span class="java-
keyword">extends</span> AuthenticatedWebApplication{
+}</pre></div><p class="paragraph"/><h3>Catching an unauthorized component instantiation</h3><p class="paragraph"/>Interface IUnauthorizedComponentInstantiationListener (in package <code>org.apache.wicket.authorization</code>) is provided to give the chance to handle the case in which a user tries to instantiate a component without having the permissions to do it. The method defined inside this interface is <code>onUnauthorizedInstantiation(Component)</code> and it is executed whenever a user attempts to execute an unauthorized instantiation.<p class="paragraph"/>This listener must be registered into application's security settings with method setUnauthorized <code>ComponentInstantiationListener</code> defined by setting interface <code>ISecuritySettings</code>. In the following code snippet we register a listener that redirect user to a warning page if he tries to do a not-allowed instantiation:<p class="paragraph"/><div class="code"><pre><span class="java-keyword">public</
span> class WicketApplication <span class="java-keyword">extends</span> AuthenticatedWebApplication{
//Application code…
@Override
<span class="java-keyword">public</span> void init(){
@@ -267,7 +267,7 @@ Application class AuthenticatedWebApplic
}
});
}
-}</pre></div><p class="paragraph"/>In addition to interface IRoleCheckingStrategy, class AuthenticatedWebApplication implements also IUnauthorizedComponentInstantiationListener and registers itself as listener for unauthorized instantiations.<p class="paragraph"/>By default AuthenticatedWebApplication redirects users to sign-in page if they are not signed-in and they try to instantiate a restricted component. Otherwise, if users are already signed in but they are not allowed to instantiate a given component, an UnauthorizedInstantiationException will be thrown.<p class="paragraph"/><h3>Strategy RoleAuthorizationStrategy</h3><p class="paragraph"/>Class RoleAuthorizationStrategy is a compound strategy that combines both MetaData RoleAuthorizationStrategy and AnnotationsRoleAuthorizationStrategy.<p class="paragraph"/>This is the strategy used internally by AuthenticatedWebApplication.
+}</pre></div><p class="paragraph"/>In addition to interface <code>IRoleCheckingStrategy</code>, class <code>AuthenticatedWebApplication</code> implements also <code>IUnauthorizedComponentInstantiationListener</code> and registers itself as listener for unauthorized instantiations.<p class="paragraph"/>By default <code>AuthenticatedWebApplication</code> redirects users to sign-in page if they are not signed-in and they try to instantiate a restricted component. Otherwise, if users are already signed in but they are not allowed to instantiate a given component, an <code>UnauthorizedInstantiationException</code> will be thrown.<p class="paragraph"/><h3>Strategy RoleAuthorizationStrategy</h3><p class="paragraph"/>Class <code>RoleAuthorizationStrategy</code> is a compound strategy that combines both <code>MetaDataRoleAuthorizationStrategy</code> and <code>AnnotationsRoleAuthorizationStrategy</code>.<p class="paragraph"/>This is the strategy used internally by <code>AuthenticatedWebA
pplication</code>.
Modified: wicket/common/site/trunk/_site/guide/guide/pages/chapter19_3.html
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/pages/chapter19_3.html?rev=1550971&r1=1550970&r2=1550971&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/pages/chapter19_3.html (original)
+++ wicket/common/site/trunk/_site/guide/guide/pages/chapter19_3.html Sat Dec 14 21:13:09 2013
@@ -157,7 +157,7 @@ function addJsClass() {
<h2 id="chapter19_3">20.3 Using HTTPS protocol</h2>
-<p class="paragraph"/>HTTPS is the standard technology adopted on Internet to create a secure communication channel between web applications and their users.<p class="paragraph"/>In Wicket we can easily protect our pages with HTTPS mounting a special request mapper called HttpsMapper and using annotation RequireHttps with those pages we want to serve over this protocol. Both these two entities are in package org.apache.wicket.protocol.https.<p class="paragraph"/>HttpsMapper wraps an existing mapper and redirects incoming requests to HTTPS if the related response must render a page containing annotation RequireHttps. Most of the times the wrapped mapper will be the root one, just like we saw before for CryptoManager in paragraph 8.6.6.<p class="paragraph"/>Another parameter needed to build a HttpsMapper is an instance of class HttpsConfig. This class allows us to specify which ports must be used for HTTPS and HTTP. By default the port numbers used by these two protocols are respectiv
ely 443 and 80.<p class="paragraph"/>The following code is taken from project HttpsProtocolExample and illustrates how to enable HTTPS in our applications:<p class="paragraph"/><div class="code"><pre>//Application class code…
+<p class="paragraph"/>HTTPS is the standard technology adopted on Internet to create a secure communication channel between web applications and their users.<p class="paragraph"/>In Wicket we can easily protect our pages with HTTPS mounting a special request mapper called <code>HttpsMapper</code> and using annotation RequireHttps with those pages we want to serve over this protocol. Both these two entities are in package <code>org.apache.wicket.protocol.https</code>.<p class="paragraph"/>HttpsMapper wraps an existing mapper and redirects incoming requests to HTTPS if the related response must render a page containing annotation <code>RequireHttps</code>. Most of the times the wrapped mapper will be the root one, just like we saw before for <code>CryptoManager</code> in paragraph 8.6.6.<p class="paragraph"/>Another parameter needed to build a <code>HttpsMapper</code> is an instance of class <code>HttpsConfi</code>g. This class allows us to specify which ports must be used for HTTPS a
nd HTTP. By default the port numbers used by these two protocols are respectively 443 and 80.<p class="paragraph"/>The following code is taken from project <code>HttpsProtocolExample</code> and illustrates how to enable HTTPS in our applications:<p class="paragraph"/><div class="code"><pre>//Application class code…
@Override
<span class="java-keyword">public</span> void init(){
setRootRequestMapper(<span class="java-keyword">new</span> HttpsMapper(getRootRequestMapper(),
@@ -167,7 +167,7 @@ function addJsClass() {
<span class="java-keyword">public</span> HomePage(<span class="java-keyword">final</span> PageParameters parameters) {
<span class="java-keyword">super</span>(parameters);
}
-}</pre></div><p class="paragraph"/>If we want to protect many pages with HTTPS without adding annotation RequireHttps to each of them, we can annotate a marker interface or a base page class and implement/extend it in any page we want to make secure:<p class="paragraph"/><div class="code"><pre>// Marker <span class="java-keyword">interface</span>:
+}</pre></div><p class="paragraph"/>If we want to protect many pages with HTTPS without adding annotation <code>RequireHttps</code> to each of them, we can annotate a marker interface or a base page class and implement/extend it in any page we want to make secure:<p class="paragraph"/><div class="code"><pre>// Marker <span class="java-keyword">interface</span>:
@RequireHttps
<span class="java-keyword">public</span> <span class="java-keyword">interface</span> IMarker{
}<p class="paragraph"/>// Base class:
Modified: wicket/common/site/trunk/_site/guide/guide/pages/chapter19_4.html
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/pages/chapter19_4.html?rev=1550971&r1=1550970&r2=1550971&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/pages/chapter19_4.html (original)
+++ wicket/common/site/trunk/_site/guide/guide/pages/chapter19_4.html Sat Dec 14 21:13:09 2013
@@ -157,7 +157,7 @@ function addJsClass() {
<h2 id="chapter19_4">20.4 Package Resource Guard</h2>
-<p class="paragraph"/>Wicket internally uses an entity called package resource guard to protect package resources from external access. This entity is an implementation of interface org.apache.wicket.markup.html. IPackageResourceGuard.<p class="paragraph"/>By default Wicket applications use as package resource guard class SecurePackageResource Guard, which allows to access only to the following file extensions (grouped by type):<p class="paragraph"/><table class="wiki-table" cellpadding="0" cellspacing="0" border="0"><tr><th>File</th><th>Extensions</th></tr><tr class="table-odd"><td><strong class="bold">JavaScript files</strong></td><td>.js</td></tr><tr class="table-even"><td><strong class="bold">CSS files</strong></td><td>.css</td></tr><tr class="table-odd"><td><strong class="bold">HTML pages</strong></td><td>.html</td></tr><tr class="table-even"><td><strong class="bold">Textual files</strong></td><td>.txt</td></tr><tr class="table-odd"><td><strong class="bold">Flash files</strong>
</td><td>.swf</td></tr><tr class="table-even"><td><strong class="bold">Picture files</strong></td><td>.png, .jpg, .jpeg, .gif, .ico, .cur, .bmp, .svg</td></tr><tr class="table-odd"><td><strong class="bold">Web font files</strong></td><td>.eot, .ttf, .woff</td></tr></table><p class="paragraph"/>To modify the set of allowed files formats we can add one or more patterns with method addPattern (String). The rules to write a pattern are the following:
+<p class="paragraph"/>Wicket internally uses an entity called package resource guard to protect package resources from external access. This entity is an implementation of interface <code>org.apache.wicket.markup.html.IPackageResourceGuard</code>.<p class="paragraph"/>By default Wicket applications use as package resource guard class <code>SecurePackageResourceGuard</code>, which allows to access only to the following file extensions (grouped by type):<p class="paragraph"/><table class="wiki-table" cellpadding="0" cellspacing="0" border="0"><tr><th>File</th><th>Extensions</th></tr><tr class="table-odd"><td><strong class="bold">JavaScript files</strong></td><td>.js</td></tr><tr class="table-even"><td><strong class="bold">CSS files</strong></td><td>.css</td></tr><tr class="table-odd"><td><strong class="bold">HTML pages</strong></td><td>.html</td></tr><tr class="table-even"><td><strong class="bold">Textual files</strong></td><td>.txt</td></tr><tr class="table-odd"><td><strong class="bo
ld">Flash files</strong></td><td>.swf</td></tr><tr class="table-even"><td><strong class="bold">Picture files</strong></td><td>.png, .jpg, .jpeg, .gif, .ico, .cur, .bmp, .svg</td></tr><tr class="table-odd"><td><strong class="bold">Web font files</strong></td><td>.eot, .ttf, .woff</td></tr></table><p class="paragraph"/>To modify the set of allowed files formats we can add one or more patterns with method <code>addPattern(String)</code>. The rules to write a pattern are the following:
<ul class="star">
<li>patterns start with either a "+" or a "-". In the first case the pattern will add one or more file to the set while starting a pattern with a â-â we exclude all the files matching the given pattern. For example pattern â-web.xmlâ excludes all web.xml files in all directories.</li>
<li>wildcard character â*â is supported as placeholder for zero or more characters. For example pattern â+*.mp4â adds all the mp4 files inside all directories.</li>