Modified: wicket/common/site/trunk/_site/guide/guide/chapter16.html
URL: 
http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/chapter16.html?rev=1550971&r1=1550970&r2=1550971&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/chapter16.html (original)
+++ wicket/common/site/trunk/_site/guide/guide/chapter16.html Sat Dec 14 
21:13:09 2013
@@ -184,7 +184,7 @@ In this chapter we will learn some advan
 
 
 <h2 id="chapter16_1">17.1 Enriching components with behaviors</h2>
-<p class="paragraph"/>With class org.apache.wicket.behavior.Behavior Wicket 
provides a very flexible mechanism to share common features across different 
components and to enrich existing components with further functionalities. As 
the class name suggests, Behavior adds a generic behavior to a component 
modifying its markup and/or contributing to the header section of the page 
(Behavior implements the interface IHeaderContributor).<p 
class="paragraph"/>One or more behaviors can be added to a component with 
Component's method add(Behavior...), while to remove a behavior we must use 
method remove(Behavior).<p class="paragraph"/>Here is a partial list of methods 
defined inside class Behavior along with a brief description of what they do:
+<p class="paragraph"/>With class 
<code>org.apache.wicket.behavior.Behavior</code> Wicket provides a very 
flexible mechanism to share common features across different components and to 
enrich existing components with further functionalities. As the class name 
suggests, <code>Behavior</code> adds a generic behavior to a component 
modifying its markup and/or contributing to the header section of the page 
(<code>Behavior</code> implements the interface 
<code>IHeaderContributor</code>).<p class="paragraph"/>One or more behaviors 
can be added to a component with <code>Component</code>'s method 
<code>add(Behavior...)</code>, while to remove a behavior we must use method 
<code>remove(Behavior)</code>.<p class="paragraph"/>Here is a partial list of 
methods defined inside class <code>Behavior</code> along with a brief 
description of what they do:
 <ul class="star">
 <li><strong class="bold">beforeRender(Component component)</strong>: called 
when a component is about to be rendered.</li>
 <li><strong class="bold">afterRender(Component component)</strong>: called 
after a component has been rendered.</li>
@@ -207,18 +207,18 @@ In this chapter we will learn some advan
       &#125;  
       response.write(asteriskHtml);
   &#125;
-&#125;</pre></div><p class="paragraph"/>Since method beforeRender is called 
before the coupled component is rendered, we can use it to prepend custom 
markup to component tag. This can be done writing our markup directly to the 
current  Response object, as we did in the example above.<p 
class="paragraph"/>Please note that we could achieve the same result overriding 
component method onBeforeRender. However using a behavior we can easily reuse 
our custom code with any other kind of component without modifying its source 
code. As general best practice we should always consider to implement a new 
functionality using a behavior if it can be shared among different kinds of 
component.<p class="paragraph"/>Behaviors play also a strategic role in the 
built-in AJAX support provided by Wicket, as we will see in the next chapter. 
+&#125;</pre></div><p class="paragraph"/>Since method <code>beforeRender</code> 
is called before the coupled component is rendered, we can use it to prepend 
custom markup to component tag. This can be done writing our markup directly to 
the current  Response object, as we did in the example above.<p 
class="paragraph"/>Please note that we could achieve the same result overriding 
component method <code>onBeforeRender</code>. However using a behavior we can 
easily reuse our custom code with any other kind of component without modifying 
its source code. As general best practice we should always consider to 
implement a new functionality using a behavior if it can be shared among 
different kinds of component.<p class="paragraph"/>Behaviors play also a 
strategic role in the built-in AJAX support provided by Wicket, as we will see 
in the next chapter. 
 
 
 
 <h2 id="chapter16_2">17.2 Generating callback URLs with IRequestListener</h2>
-<p class="paragraph"/>With Wicket it's quite easy to build a callback URL that 
executes a specific method on server side. This method must be defined in a 
functional interface (i.e. an an interface that defines just one method) that 
inherits from built-in org.apache.wicket.IRequestListener and it must be a void 
method with no parameters in input:<p class="paragraph"/><div 
class="code"><pre><span class="java&#45;keyword">public</span> <span 
class="java&#45;keyword">interface</span> IMyListener <span 
class="java&#45;keyword">extends</span> IRequestListener
+<p class="paragraph"/>With Wicket it's quite easy to build a callback URL that 
executes a specific method on server side. This method must be defined in a 
functional interface (i.e. an an interface that defines just one method) that 
inherits from built-in <code>org.apache.wicket.IRequestListener</code> and it 
must be a void method with no parameters in input:<p class="paragraph"/><div 
class="code"><pre><span class="java&#45;keyword">public</span> <span 
class="java&#45;keyword">interface</span> IMyListener <span 
class="java&#45;keyword">extends</span> IRequestListener
 &#123;
        /&#42;&#42;
         &#42; Called when the relative callback URL is requested.
         &#42;/
        void myCallbackMethod();
-&#125;</pre></div><p class="paragraph"/>To control how the method will be 
invoked we must use class org.apache.wicket.RequestListenerInterface. In Wicket 
is a common practice to instantiate this class as a public static field inside 
the relative callback interface:<p class="paragraph"/><div 
class="code"><pre><span class="java&#45;keyword">public</span> <span 
class="java&#45;keyword">interface</span> IMyListener <span 
class="java&#45;keyword">extends</span> IRequestListener
+&#125;</pre></div><p class="paragraph"/>To control how the method will be 
invoked we must use class 
<code>org.apache.wicket.RequestListenerInterface</code>. In Wicket is a common 
practice to instantiate this class as a public static field inside the relative 
callback interface:<p class="paragraph"/><div class="code"><pre><span 
class="java&#45;keyword">public</span> <span 
class="java&#45;keyword">interface</span> IMyListener <span 
class="java&#45;keyword">extends</span> IRequestListener
 &#123;
        /&#42;&#42;RequestListenerInterface instance&#42;/
        <span class="java&#45;keyword">public</span> <span 
class="java&#45;keyword">static</span> <span 
class="java&#45;keyword">final</span> RequestListenerInterface INTERFACE = 
<span class="java&#45;keyword">new</span> 
@@ -227,14 +227,14 @@ In this chapter we will learn some advan
         &#42; Called when the relative callback URL is requested.
         &#42;/
        void myCallbackMethod();
-&#125;</pre></div><p class="paragraph"/>By default RequestListenerInterface 
will respond rendering the current page after the callback method has been 
executed (if we have a non-AJAX request). To change this behavior we can use 
setter method setRenderPageAfterInvocation(boolean).<p class="paragraph"/>Now 
that our callback interface is complete we can generate a callback URL with 
Component's method urlFor(RequestListenerInterface, PageParameters) or with 
method urlFor (Behavior, RequestListenerInterface, PageParameters) if we are 
using a callback interface with a behavior (see the following example).<p 
class="paragraph"/>Project CallbackURLExample contains a behavior (class 
OnChangeSingleChoiceBehavior) that implements a callback interface to update 
the model of an AbstractSingleSelectChoice component when user changes the 
selected option (it provides the same functionality of method want 
OnSelectionChangedNotifications).<p class="paragraph"/>Instead of a custom 
callback interface, O
 nChangeSingleChoiceBehavior implements built-in interface 
org.apache.wicket.behavior.IBehaviorListener which is designed to generate a 
callback URL for behaviors. The callback method defined in this interface is 
onRequest() and the following is the implementation provided by 
OnSelectionChangedNotifications:<p class="paragraph"/><div 
class="code"><pre>@Override
+&#125;</pre></div><p class="paragraph"/>By default 
<code>RequestListenerInterface</code> will respond rendering the current page 
after the callback method has been executed (if we have a non-AJAX request). To 
change this behavior we can use setter method 
<code>setRenderPageAfterInvocation(boolean)</code>.<p class="paragraph"/>Now 
that our callback interface is complete we can generate a callback URL with 
<code>Component</code>'s method <code>urlFor(RequestListenerInterface, 
PageParameters)</code> or with method <code>urlFor (Behavior, 
RequestListenerInterface, PageParameters)</code> if we are using a callback 
interface with a behavior (see the following example).<p 
class="paragraph"/>Project CallbackURLExample contains a behavior (class 
<code>OnChangeSingleChoiceBehavior</code>) that implements a callback interface 
to update the model of an <code>AbstractSingleSelectChoice</code> component 
when user changes the selected option (it provides the same functionality of 
method <code>want
 OnSelectionChangedNotifications</code>).<p class="paragraph"/>Instead of a 
custom callback interface, <code>OnChangeSingleChoiceBehavior</code> implements 
built-in interface <code>org.apache.wicket.behavior.IBehaviorListener</code> 
which is designed to generate a callback URL for behaviors. The callback method 
defined in this interface is <code>onRequest()</code> and the following is the 
implementation provided by <code>OnSelectionChangedNotifications</code>:<p 
class="paragraph"/><div class="code"><pre>@Override
 <span class="java&#45;keyword">public</span> void onRequest() &#123;   
        Request request = RequestCycle.get().getRequest();
        IRequestParameters requestParameters = request.getRequestParameters();
        StringValue choiceId = requestParameters.getParameterValue(<span 
class="java&#45;quote">"choiceId"</span>);
        //boundComponent is the component that the behavior it is bound to.
        boundComponent.setDefaultModelObject( 
convertChoiceIdToChoice(choiceId.toString()));
-&#125;</pre></div><p class="paragraph"/>When invoked via URL, the behavior 
expects to find a request parameter (choiceId) containing the id of the 
selected choice. This value is used to obtain the corresponding choice object 
that must be used to set the model of the component that the behavior is bound 
to (boundComponent). Method convertChoiceIdToChoice is in charge of retrieving 
the choice object given its id and it has been copied from class 
AbstractSingleSelectChoice.<p class="paragraph"/>Another interesting part of 
OnChangeSingleChoiceBehavior is its method onComponentTag where some JavaScript 
“magic” is used to move user's browser to the callback URL when event 
“change” occurs on bound component:<p class="paragraph"/><div 
class="code"><pre>@Override
+&#125;</pre></div><p class="paragraph"/>When invoked via URL, the behavior 
expects to find a request parameter (choiceId) containing the id of the 
selected choice. This value is used to obtain the corresponding choice object 
that must be used to set the model of the component that the behavior is bound 
to (boundComponent). Method <code>convertChoiceIdToChoice</code> is in charge 
of retrieving the choice object given its id and it has been copied from class 
<code>AbstractSingleSelectChoice</code>.<p class="paragraph"/>Another 
interesting part of <code>OnChangeSingleChoiceBehavior</code> is its method 
<code>onComponentTag</code> where some JavaScript “magic” is used to move 
user's browser to the callback URL when event “change” occurs on bound 
component:<p class="paragraph"/><div class="code"><pre>@Override
 <span class="java&#45;keyword">public</span> void onComponentTag(Component 
component, ComponentTag tag) &#123;
        <span class="java&#45;keyword">super</span>.onComponentTag(component, 
tag);<p class="paragraph"/>       CharSequence callBackURL = getCallbackUrl();
        <span class="java&#45;object">String</span> separatorChar = 
(callBackURL.toString().indexOf('?') &#62; &#45;1 ? <span 
class="java&#45;quote">"&#38;"</span> : <span 
class="java&#45;quote">"?"</span>);<p class="paragraph"/>   <span 
class="java&#45;object">String</span> finalScript = <span 
class="java&#45;quote">"<span class="java&#45;keyword">var</span> isSelect = 
$(<span class="java&#45;keyword">this</span>).is('select');&#110;"</span> +
@@ -245,23 +245,23 @@ In this chapter we will learn some advan
                                 <span class="java&#45;quote">" component = 
$(<span 
class="java&#45;keyword">this</span>).find('input:radio:checked');&#110;"</span>
 +
                                 <span 
class="java&#45;quote">"window.location.href='"</span> + callBackURL +  
separatorChar + 
                                 <span class="java&#45;quote">"choiceId=' + 
"</span> + <span class="java&#45;quote">"component.val()"</span>;<p 
class="paragraph"/>     tag.put(<span class="java&#45;quote">"onchange"</span>, 
finalScript);
-&#125;</pre></div><p class="paragraph"/>The goal of onComponentTag is to build 
an onchange handler that forces user's browser to move to the callback URL 
(modifing standard property window.location.href). Please note that we have 
appended the expected parameter (choiceId) to the URL retrieving its value with 
a JQuery selector suited for the current type of component (a drop-down menu or 
a radio group). Since we are using JQuery in our JavaScript code, the behavior 
comes also with method renderHead that adds the bundled JQuery library to the 
current page.<p class="paragraph"/>Method getCallbackUrl() is used to generate 
the callback URL for our custom behavior and it has been copied from built-in 
class AbstractAjaxBehavior:<p class="paragraph"/><div class="code"><pre><span 
class="java&#45;keyword">public</span> CharSequence getCallbackUrl()&#123;
+&#125;</pre></div><p class="paragraph"/>The goal of 
<code>onComponentTag</code> is to build an onchange handler that forces user's 
browser to move to the callback URL (modifing standard property 
window.location.href). Please note that we have appended the expected parameter 
(choiceId) to the URL retrieving its value with a JQuery selector suited for 
the current type of component (a drop-down menu or a radio group). Since we are 
using JQuery in our JavaScript code, the behavior comes also with method 
<code>renderHead</code> that adds the bundled JQuery library to the current 
page.<p class="paragraph"/>Method <code>getCallbackUrl()</code> is used to 
generate the callback URL for our custom behavior and it has been copied from 
built-in class <code>AbstractAjaxBehavior</code>:<p class="paragraph"/><div 
class="code"><pre><span class="java&#45;keyword">public</span> CharSequence 
getCallbackUrl()&#123;
        <span class="java&#45;keyword">if</span> (boundComponent == <span 
class="java&#45;keyword">null</span>)&#123;
                <span class="java&#45;keyword">throw</span> <span 
class="java&#45;keyword">new</span> IllegalArgumentException(
                        <span class="java&#45;quote">"Behavior must be bound to 
a component to create the URL"</span>);
        &#125;<p class="paragraph"/>    <span 
class="java&#45;keyword">final</span> RequestListenerInterface rli;<p 
class="paragraph"/> rli = IBehaviorListener.INTERFACE;<p class="paragraph"/>    
    <span class="java&#45;keyword">return</span> boundComponent.urlFor(<span 
class="java&#45;keyword">this</span>, rli, <span 
class="java&#45;keyword">new</span> PageParameters());
-&#125;</pre></div><p class="paragraph"/>Static field 
IBehaviorListener.INTERFACE is the implementation of RequestListenerInterface 
defined inside callback interface IBehaviorListener.<p class="paragraph"/>The 
home page of project CallbackURLExample contains a DropDownChoice and a 
RadioChoice which use our custom behavior. There are also two labels to display 
the content of the models of the two components:<p class="paragraph"/><img 
border="0" class="center" 
src="../img/CallbackURLExample-screenshot.png"></img><p 
class="paragraph"/><blockquote class="note">
-Implementing interface IBehaviorListener makes a behavior stateful because its 
callback URL is specific for a given instance of component.
+&#125;</pre></div><p class="paragraph"/>Static field 
<code>IBehaviorListener.INTERFACE</code> is the implementation of 
<code>RequestListenerInterface</code> defined inside callback interface 
<code>IBehaviorListener</code>.<p class="paragraph"/>The home page of project 
<code>CallbackURLExample</code> contains a <code>DropDownChoice</code> and a 
<code>RadioChoice</code> which use our custom behavior. There are also two 
labels to display the content of the models of the two components:<p 
class="paragraph"/><img border="0" class="center" 
src="../img/CallbackURLExample-screenshot.png"></img><p 
class="paragraph"/><blockquote class="note">
+Implementing interface <code>IBehaviorListener</code> makes a behavior 
stateful because its callback URL is specific for a given instance of component.
 </blockquote><p class="paragraph"/>
-<h3>Wicket events infrastructure</h3><p class="paragraph"/>Starting from 
version 1.5 Wicket offers an event-based infrastructure for inter-component 
communication. The infrastructure is based on two simple interfaces (both in 
package org.apache.wicket.event) : IEventSource and IEventSink.<p 
class="paragraph"/>The first interface must be implemented by those entities 
that want to broadcast en event while the second interface must be implemented 
by those entities that want to receive a broadcast event.<p 
class="paragraph"/>The following entities already implement both these two 
interfaces (i.e. they can be either sender or receiver): Component, Session, 
RequestCycle and Application.
-IEventSource exposes a single method named send which takes in input three 
parameters:
+<h3>Wicket events infrastructure</h3><p class="paragraph"/>Starting from 
version 1.5 Wicket offers an event-based infrastructure for inter-component 
communication. The infrastructure is based on two simple interfaces (both in 
package <code>org.apache.wicket.event</code>) : <code>IEventSource</code> and 
<code>IEventSink</code>.<p class="paragraph"/>The first interface must be 
implemented by those entities that want to broadcast en event while the second 
interface must be implemented by those entities that want to receive a 
broadcast event.<p class="paragraph"/>The following entities already implement 
both these two interfaces (i.e. they can be either sender or receiver): 
<code>Component</code>, <code>Session</code>, <code>RequestCycle</code> and 
<code>Application</code>.
+<code>IEventSource</code> exposes a single method named send which takes in 
input three parameters:
 <ul class="star">
-<li><strong class="bold">sink</strong>: an implementation of IEventSink that 
will be the receiver of the event.</li>
-<li><strong class="bold">broadcast</strong>: a Broadcast enum which defines 
the broadcast method used to dispatch the event to the sink and to other 
entities such as sink children, sink containers, session object, application 
object and the current request cycle. It has four possible values:</li>
+<li><strong class="bold">sink</strong>: an implementation of 
<code>IEventSink</code> that will be the receiver of the event.</li>
+<li><strong class="bold">broadcast</strong>: a <code>Broadcast</code> enum 
which defines the broadcast method used to dispatch the event to the sink and 
to other entities such as sink children, sink containers, session object, 
application object and the current request cycle. It has four possible 
values:</li>
 </ul><p class="paragraph"/><table class="wiki-table" cellpadding="0" 
cellspacing="0" border="0"><tr><th><strong 
class="bold">Value</strong></th><th><strong 
class="bold">Description</strong></th></tr><tr 
class="table-odd"><td>BREADTH</td><td>The event is sent first to the specified 
sink and then to all its children components following a breadth-first 
order.</td></tr><tr class="table-even"><td>DEPTH</td><td>The event is sent to 
the specified sink only after it has been dispatched to all its children 
components following a depth-first order.</td></tr><tr 
class="table-odd"><td>BUBBLE</td><td>The event is sent first to the specified 
sink and then to its parent containers.</td></tr><tr 
class="table-even"><td>EXACT</td><td>The event is sent only to the specified 
sink.</td></tr></table>
 <ul class="star">
 <li><strong class="bold">payload</strong>: a generic object representing the 
data sent with the event.</li>
-</ul><p class="paragraph"/>Each broadcast mode has its own traversal order for 
Session, RequestCycle and Application. See JavaDoc of class Broadcast for 
further details about this order.<p class="paragraph"/>Interface IEventSink 
exposes callback method onEvent(IEvent&#60;?&#62; event) which is triggered 
when a sink receives an event. The interface IEvent represents the received 
event and provides getter methods to retrieve the event broadcast type, the 
source of the event and its payload. Typically the received event is used 
checking the type of its payload object:<p class="paragraph"/><div 
class="code"><pre>@Override
+</ul><p class="paragraph"/>Each broadcast mode has its own traversal order for 
<code>Session</code>, <code>RequestCycle</code> and <code>Application</code>. 
See JavaDoc of class <code>Broadcast</code> for further details about this 
order.<p class="paragraph"/>Interface <code>IEventSink</code> exposes callback 
method <code>onEvent(IEvent&#60;?&#62; event)</code> which is triggered when a 
sink receives an event. The interface <code>IEvent</code> represents the 
received event and provides getter methods to retrieve the event broadcast 
type, the source of the event and its payload. Typically the received event is 
used checking the type of its payload object:<p class="paragraph"/><div 
class="code"><pre>@Override
 <span class="java&#45;keyword">public</span> void onEvent(IEvent event) &#123;
   //<span class="java&#45;keyword">if</span> the type of payload is 
MyPayloadClass perform some actions 
   <span class="java&#45;keyword">if</span>(event.getPayload() <span 
class="java&#45;keyword">instanceof</span> MyPayloadClass) &#123;
@@ -269,12 +269,12 @@ IEventSource exposes a single method nam
   &#125;<span class="java&#45;keyword">else</span>&#123;
      //other business code
   &#125;               
-&#125;</pre></div><p class="paragraph"/>Project InterComponetsEventsExample 
provides a concrete example of sending an event to a component (named 
'container in the middle') using all the available broadcast methods:<p 
class="paragraph"/><img border="0" class="center" 
src="../img/InterComponentsEventsExample-screenshot.png"></img>
+&#125;</pre></div><p class="paragraph"/>Project 
<code>InterComponetsEventsExample</code> provides a concrete example of sending 
an event to a component (named 'container in the middle') using all the 
available broadcast methods:<p class="paragraph"/><img border="0" 
class="center" src="../img/InterComponentsEventsExample-screenshot.png"></img>
 
 
 
 <h2 id="chapter16_3">17.3 Initializers</h2>
-<p class="paragraph"/>Some components or resources may need to be configured 
before being used in our applications. While so far we used Application's init 
method to initialize these kinds of entities, Wicket offers a more flexible and 
modular way to configure our classes.<p class="paragraph"/>During application's 
bootstrap Wicket searches for any properties file named wicket.properties  
placed in one of the classpath roots visible to the application. When one of 
these files is found, the initializer defined inside it will be executed. An 
initializer is an implementation of interface org.apache.wicket.IInitializer 
and is defined inside wicket.properties with a line like this:<p 
class="paragraph"/><div 
class="code"><pre>initializer=org.wicketTutorial.MyInitializer</pre></div><p 
class="paragraph"/>The fully qualified class name corresponds to the 
initializer that must be executed. Interface IInitializer defines method 
init(Application) which should contain our initialization code, and
  method destroy(Application) which is invoked when application is 
terminated:<p class="paragraph"/><div class="code"><pre><span 
class="java&#45;keyword">public</span> class MyInitializer <span 
class="java&#45;keyword">implements</span> IInitializer&#123;<p 
class="paragraph"/>   <span class="java&#45;keyword">public</span> void 
init(Application application) &#123;
+<p class="paragraph"/>Some components or resources may need to be configured 
before being used in our applications. While so far we used Application's init 
method to initialize these kinds of entities, Wicket offers a more flexible and 
modular way to configure our classes.<p class="paragraph"/>During application's 
bootstrap Wicket searches for any properties file named wicket.properties  
placed in one of the classpath roots visible to the application. When one of 
these files is found, the initializer defined inside it will be executed. An 
initializer is an implementation of interface 
<code>org.apache.wicket.IInitializer</code> and is defined inside 
wicket.properties with a line like this:<p class="paragraph"/><div 
class="code"><pre>initializer=org.wicketTutorial.MyInitializer</pre></div><p 
class="paragraph"/>The fully qualified class name corresponds to the 
initializer that must be executed. Interface <code>IInitializer</code> defines 
method init(Application) which should contain ou
 r initialization code, and method <code>destroy(Application)</code> which is 
invoked when application is terminated:<p class="paragraph"/><div 
class="code"><pre><span class="java&#45;keyword">public</span> class 
MyInitializer <span class="java&#45;keyword">implements</span> 
IInitializer&#123;<p class="paragraph"/>    <span 
class="java&#45;keyword">public</span> void init(Application application) &#123;
                //initialization code 
        &#125;<p class="paragraph"/>    <span 
class="java&#45;keyword">public</span> void destroy(Application application) 
&#123;
                //code to execute when application is terminated
@@ -289,11 +289,11 @@ IEventSource exposes a single method nam
 
 
 <h2 id="chapter16_4">17.4 Using JMX with Wicket</h2>
-<p class="paragraph"/>JMX (Java Management Extensions) is the standard 
technology adopted in Java for managing and monitoring running applications or 
Java Virtual Machines. Wicket offers support for JMX through module wicket-jmx. 
In this paragraph we will see how we can connect to a Wicket application using 
JMX. In our example we will use JConsole as JMX client. This program is bundled 
with Java SE since version 5 and we can run it typing jconsole in our OS 
shell.<p class="paragraph"/>Once JConsole has started it will ask us to 
establish a new connection to a Java process, choosing between a local process 
or a remote one. In the following picture we have selected the process 
corresponding to the local instance of Jetty server we used to run one of our 
example projects:<p class="paragraph"/><img border="0" class="center" 
src="../img/JMX-new-connection.png"></img><p class="paragraph"/>After we have 
established a JMX connection, JConsole will show us the following set of 
tabs:<p class=
 "paragraph"/><img border="0" class="center" 
src="../img/JMX-console.png"></img><p class="paragraph"/>JMX exposes 
application-specific informations using special objects called MBeans 
(Manageable Beans), hence if we want to control our application we must open 
the corresponding tab. The MBeans containing the application's informations is 
named org.apache.wicket.app.&#60;filter/servlet name&#62;.<p 
class="paragraph"/>In our example we have used wicket.test as filter name for 
our application:<p class="paragraph"/><img border="0" class="center" 
src="../img/JMX-console2.png"></img><p class="paragraph"/>As we can see in the 
picture above, every MBean exposes a node containing its attributes and another 
node showing the possible operations that can be performed on the object. In 
the case of a Wicket application the available operations are clearMarkupCache 
and clearLocalizerCache:<p class="paragraph"/><img border="0" class="center" 
src="../img/JMX-console3.png"></img><p class="paragraph"/>
 With these two operations we can force Wicket to clear the internal caches 
used to load components markup and resource bundles. This can be particularly 
useful if we have our application running in DEPLOYMENT mode and we want to 
publish minor fixes for markup or bundle files (like spelling or typo 
corrections) without restarting the entire application. Without cleaning these 
two caches Wicket would continue to use cached values ignoring any change made 
to markup or bundle files.<p class="paragraph"/>Some of the exposed properties 
are editable, hence we can tune their values while the application is running. 
For example if we look at the properties of ApplicationSettings we can set the 
maximum size allowed for an upload modifying the attribute 
DefaultMaximumUploadSize:<p class="paragraph"/><img border="0" class="center" 
src="../img/JMX-console4.png"></img>
+<p class="paragraph"/>JMX (Java Management Extensions) is the standard 
technology adopted in Java for managing and monitoring running applications or 
Java Virtual Machines. Wicket offers support for JMX through module wicket-jmx. 
In this paragraph we will see how we can connect to a Wicket application using 
JMX. In our example we will use JConsole as JMX client. This program is bundled 
with Java SE since version 5 and we can run it typing jconsole in our OS 
shell.<p class="paragraph"/>Once JConsole has started it will ask us to 
establish a new connection to a Java process, choosing between a local process 
or a remote one. In the following picture we have selected the process 
corresponding to the local instance of Jetty server we used to run one of our 
example projects:<p class="paragraph"/><img border="0" class="center" 
src="../img/JMX-new-connection.png"></img><p class="paragraph"/>After we have 
established a JMX connection, JConsole will show us the following set of 
tabs:<p class=
 "paragraph"/><img border="0" class="center" 
src="../img/JMX-console.png"></img><p class="paragraph"/>JMX exposes 
application-specific informations using special objects called MBeans 
(Manageable Beans), hence if we want to control our application we must open 
the corresponding tab. The MBeans containing the application's informations is 
named <code>org.apache.wicket.app.&#60;filter/servlet name&#62;</code>.<p 
class="paragraph"/>In our example we have used wicket.test as filter name for 
our application:<p class="paragraph"/><img border="0" class="center" 
src="../img/JMX-console2.png"></img><p class="paragraph"/>As we can see in the 
picture above, every MBean exposes a node containing its attributes and another 
node showing the possible operations that can be performed on the object. In 
the case of a Wicket application the available operations are clearMarkupCache 
and clearLocalizerCache:<p class="paragraph"/><img border="0" class="center" 
src="../img/JMX-console3.png"></img><p class=
 "paragraph"/>With these two operations we can force Wicket to clear the 
internal caches used to load components markup and resource bundles. This can 
be particularly useful if we have our application running in DEPLOYMENT mode 
and we want to publish minor fixes for markup or bundle files (like spelling or 
typo corrections) without restarting the entire application. Without cleaning 
these two caches Wicket would continue to use cached values ignoring any change 
made to markup or bundle files.<p class="paragraph"/>Some of the exposed 
properties are editable, hence we can tune their values while the application 
is running. For example if we look at the properties of 
<code>ApplicationSettings</code> we can set the maximum size allowed for an 
upload modifying the attribute DefaultMaximumUploadSize:<p 
class="paragraph"/><img border="0" class="center" 
src="../img/JMX-console4.png"></img>
 
 
 <h2 id="chapter16_5">17.5 Generating HTML markup from code</h2>
-<p class="paragraph"/>So far, as markup source for our pages/panels we have 
used a static markup file, no matter if it was inherited or directly associated 
to the component. Now we want to investigate a more complex use case where we 
want to dynamical generate the markup directly inside component code.<p 
class="paragraph"/>To become a markup producer, a component must simply 
implement interface org.apache.wicket.markup.IMarkupResourceStreamProvider. The 
only method defined in this interface is 
getMarkupResourceStream(MarkupContainer, Class&#60;?&#62;) which returns an 
utility interface called IResourceStream representing the actual markup.<p 
class="paragraph"/>In the following example we have a custom panel without a 
related markup file that generates a simple &#60;div&#62; tag as markup:<p 
class="paragraph"/><div class="code"><pre><span 
class="java&#45;keyword">public</span> class AutoMarkupGenPanel <span 
class="java&#45;keyword">extends</span> Panel <span class="java&#45;keyword">
 implements</span> IMarkupResourceStreamProvider &#123;
+<p class="paragraph"/>So far, as markup source for our pages/panels we have 
used a static markup file, no matter if it was inherited or directly associated 
to the component. Now we want to investigate a more complex use case where we 
want to dynamical generate the markup directly inside component code.<p 
class="paragraph"/>To become a markup producer, a component must simply 
implement interface 
<code>org.apache.wicket.markup.IMarkupResourceStreamProvider</code>. The only 
method defined in this interface is 
<code>getMarkupResourceStream(MarkupContainer, Class&#60;?&#62;)</code> which 
returns an utility interface called <code>IResourceStream</code> representing 
the actual markup.<p class="paragraph"/>In the following example we have a 
custom panel without a related markup file that generates a simple 
&#60;div&#62; tag as markup:<p class="paragraph"/><div class="code"><pre><span 
class="java&#45;keyword">public</span> class AutoMarkupGenPanel <span 
class="java&#45;keyword">extends</span
 > Panel <span class="java&#45;keyword">implements</span> 
 > IMarkupResourceStreamProvider &#123;
        <span class="java&#45;keyword">public</span> AutoMarkupGenPanel(<span 
class="java&#45;object">String</span> id, IModel&#60;?&#62; model) &#123;
                <span class="java&#45;keyword">super</span>(id, model);         
        &#125;<p class="paragraph"/>    @Override
@@ -302,7 +302,7 @@ IEventSource exposes a single method nam
                <span class="java&#45;object">String</span> markup = <span 
class="java&#45;quote">"&#60;div&#62;Panel markup&#60;/div&#62;"</span>;
                StringResourceStream resourceStream = <span 
class="java&#45;keyword">new</span> StringResourceStream(markup);<p 
class="paragraph"/>             <span class="java&#45;keyword">return</span> 
resourceStream;
        &#125;
-&#125;</pre></div><p class="paragraph"/>Class StringResourceStream is a 
resource stream that uses a String instance as backing object.<p 
class="paragraph"/><h3>Avoiding markup caching</h3><p class="paragraph"/>As we 
have seen in the previous paragraph, Wicket uses an internal cache for 
components markup. This can be a problem if our component dynamical generates 
its markup when it is rendered because once the markup has been cached, Wicket 
will always use the cached version for the specific component. To overwrite 
this default caching policy, a component can implement interface 
IMarkupCacheKeyProvider.<p class="paragraph"/>This interface defines method 
getCacheKey(MarkupContainer, Class&#60;?&#62;) which returns a string value 
representing the key used by Wicket to retrieve the markup of the component 
from the cache. If this value is null the markup will not be cached, allowing 
the component to display the last generated markup each time it is rendered:<p 
class="paragraph"/><div cla
 ss="code"><pre><span class="java&#45;keyword">public</span> class 
NoCacheMarkupPanel <span class="java&#45;keyword">extends</span> Panel <span 
class="java&#45;keyword">implements</span> IMarkupCacheKeyProvider &#123;
+&#125;</pre></div><p class="paragraph"/>Class StringResourceStream is a 
resource stream that uses a String instance as backing object.<p 
class="paragraph"/><h3>Avoiding markup caching</h3><p class="paragraph"/>As we 
have seen in the previous paragraph, Wicket uses an internal cache for 
components markup. This can be a problem if our component dynamical generates 
its markup when it is rendered because once the markup has been cached, Wicket 
will always use the cached version for the specific component. To overwrite 
this default caching policy, a component can implement interface 
<code>IMarkupCacheKeyProvider</code>.<p class="paragraph"/>This interface 
defines method <code>getCacheKey(MarkupContainer, Class&#60;?&#62;)</code> 
which returns a string value representing the key used by Wicket to retrieve 
the markup of the component from the cache. If this value is null the markup 
will not be cached, allowing the component to display the last generated markup 
each time it is rendered:<p c
 lass="paragraph"/><div class="code"><pre><span 
class="java&#45;keyword">public</span> class NoCacheMarkupPanel <span 
class="java&#45;keyword">extends</span> Panel <span 
class="java&#45;keyword">implements</span> IMarkupCacheKeyProvider &#123;
        <span class="java&#45;keyword">public</span> NoCacheMarkupPanel(<span 
class="java&#45;object">String</span> id, IModel&#60;?&#62; model) &#123;
                <span class="java&#45;keyword">super</span>(id, model);         
        &#125;<p class="paragraph"/>    /&#42;&#42;


Reply via email to