Re: UI Layout
Hi guys ... I have the same little issue and don't know how to resolve this ... I work on 2 really big projects One is a newspaper web site and other is more of a b2b application. So for newspaper web site, showing all kinds of news and stuff I'm trying with 1 page approach. Reasons: - loads of sub pages in navigation (like 100 - 200 pages and counting) . so making so many classes and markup is nonsense (or let's say .. I'd rather SHOOT myself in a foot) - layouts change just a little bit on every page, so having 100-200 different layout files is crazy B2B application is not that complicated .. it has fixed number of pages and several billion different components .. When I was working with PHP, years ago, we had a simple framework for creating our web pages. BUT the idea was a bit more simpler ... We had a page layout with panels ( to say it the wicket way, cause we called them placeholders) representing header, footer, and content columns. In those panels we rendered different components (news, article, navigation ..) . We dynamically read from configuration what layout to use for a singe page and what components to load to it's panels. We also made a simple managing page, so it was possible to simply define everything there. And now I have to do this in wicket. I need to change page layout markup file( since markup files will have my panels defines). So if someone can tell me how to do that, I would really appreciate it. please note that I'm only starting to use wicket and consider me as a 2 week wicket noob. Kind regards Armando -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288378.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UI Layout
Hi bro, so I need to change page layout markup file( since markup files will have my panels defines) 1. Use Inheritance: What I like about inheritance is you can template and further sub-template without a single line of Java (except for empty class files to represent the page ..I have a solution for this also.. read on). (There is some debate on improving inheritance http://apache-wicket.1842946.n4.nabble.com/Single-inheritence-in-parts-td2278064.html#a2278064; but lets skip that) layouts change just a little bit on every page, so having 100-200 different layout files is crazy -- With good designed templates this should be avoidable. And if not, panels can be used. 2. I need to change page layout markup file (since markup files will have my panels defines) -- So, you dont need to use PANEL's only. As explained above I believe inheritance is powerful where there is a lot of common stuff. The dynamic stuff like news, article, navigation are panels that too embedded inside the template. So the combination should reduce your combinatorial explosion! 3. Ah regarding Class files: Well this is something bothering me as well. I'm looking at CGLIB byte code generation to read the file system for markup files and auto generate java classes into the ClassLoader. So there is no need to write dumb classes. ..but this is work in progress. Just sharing the idea if anyone can beat me to it :) Please note that Im relatively new to wicket too, but through my initial frustrating experiences I learnt somethings that i hope will help you. If not, am sure the more experienced guys here will be providing valuable input. -good luck! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288432.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UI Layout
Hey ... 10x for fast reply .. I am considering inheritance cause many stuff will be reusable but I have a little tiny problem with my components and trying to figure it out ... let me try to show an example I have my custom component that shows news, labels etc. These news can be categorized, so my news component is used on a page to show different type of news (lets say .. I have 4 columns, and this component is used 4 times showing different category of news in each) so far so good .. The wicket way to do this is just use wicket:id tag wherever I want to show my news component .. BUT .. I have a little problem with this in real world and real application. My columns are just panels to hold my components and unfortunate enough, I as a developer, cannot hard code what components must be rendered in each column, cause there are so many possibilities. In one case editors will use 4 columns to show news, on second case they will only use 2 columns for news and 2 for banners and these cases go on and on and on .. never ending story .. so to do this dynamically I created layout with 4 columns and now I'm trying to render my components into that columns without specifying tags with wicket:id in every column and every possible case ... I thought that if I create my custom component with markup file .. and then add this component to my column in page would render my component .. but .. it's not :( ... so if someone can point me to the right direction with this case .. that would be something ... my custom label panel markup file: wicket:panel p This is a custom test label /p /wicket:panel java for adding my custom label panel: left.add(new CustomLabelPanel(custom-label-panel)); And of course this will not work since (as I wrote before) custom-label-panel is never defined in columns in my layout .. I guess you already figured out that I'm too lazy to put tags in for every possible case customer might come up with. So any help will be greatly appreciated. Kind regards Armando -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288518.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UI Layout
why not use repeaters for things you don't know in advance? Ernesto On Wed, Jul 14, 2010 at 12:09 PM, armandoxxx armando@dropchop.com wrote: Hey ... 10x for fast reply .. I am considering inheritance cause many stuff will be reusable but I have a little tiny problem with my components and trying to figure it out ... let me try to show an example I have my custom component that shows news, labels etc. These news can be categorized, so my news component is used on a page to show different type of news (lets say .. I have 4 columns, and this component is used 4 times showing different category of news in each) so far so good .. The wicket way to do this is just use wicket:id tag wherever I want to show my news component .. BUT .. I have a little problem with this in real world and real application. My columns are just panels to hold my components and unfortunate enough, I as a developer, cannot hard code what components must be rendered in each column, cause there are so many possibilities. In one case editors will use 4 columns to show news, on second case they will only use 2 columns for news and 2 for banners and these cases go on and on and on .. never ending story .. so to do this dynamically I created layout with 4 columns and now I'm trying to render my components into that columns without specifying tags with wicket:id in every column and every possible case ... I thought that if I create my custom component with markup file .. and then add this component to my column in page would render my component .. but .. it's not :( ... so if someone can point me to the right direction with this case .. that would be something ... my custom label panel markup file: wicket:panel p This is a custom test label /p /wicket:panel java for adding my custom label panel: left.add(new CustomLabelPanel(custom-label-panel)); And of course this will not work since (as I wrote before) custom-label-panel is never defined in columns in my layout .. I guess you already figured out that I'm too lazy to put tags in for every possible case customer might come up with. So any help will be greatly appreciated. Kind regards Armando -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288518.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UI Layout
hi .. can you explain what you mean, cause I'm not sure what you mean ... King regards Armando -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288618.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UI Layout
Hi Armando, I mean make custom-label-panel a repeater so that you can dynamically add anything you need. Best, Ernesto On Wed, Jul 14, 2010 at 1:56 PM, armandoxxx armando@dropchop.com wrote: hi .. can you explain what you mean, cause I'm not sure what you mean ... King regards Armando -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288618.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UI Layout
Hey .. 10x for your reply .. I tried what you suggested but it's not working ...and the way wicket works of course not.. you need wicket:id in a markup and I don't want to write it ... cause I'll probably die before i cover all cases needed by customer... but hey .. 10x again for tryin Kind regards Armando -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288714.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UI Layout
ok, so you mention wicket:id as if its some constant thing. Conceptually a markup tahhed by wicket-id, is no less powerful than injecting a scriptlet or any dynamic script you inject via JSP, PHP. Its like a reference point/range. Who says that anything between that wicket:id condemns you to the markup there? Thats what components are for. There are plenty of bases level components for you to choose, override and customize. SO once we've go through inheritance, panels the 2% that us not templatizable and falls under dynamic category will surely be replacable by some component. I'd recommend you read up on available components. I think this is an issue of perception that anything between wicket:id is static! Mabe Im wrong in understanding your real problem but I'd simply say there isnt anything you can do with JSP, JSTL, PHP that you can do with wicket! ..ok a bold statement :p Guys mack me up! haha kidding. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288872.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UI Layout
Hey all I finally figured out how to do it ... yes it helped to use ListView but at first I did not notice .setReuseItems(boolean) function ... after reading this article http://www.javaworld.com/javaworld/jw-07-2008/jw-07-wicket2.html?page=1 I figured out how to draw whatever I want into my column component ! Kind regards Armando -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/UI-Layout-tp1891867p2288897.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UI Layout
abstract methods you please. Furthermore, one can generalize this to a page hierarchy of any depth, since a semi-base page can define additional abstract methods to be called by its implementation of createPanel_A() or createPanel_B(). -Frank -Original Message- From: nino martinez wael [mailto:nino.martinez.w...@gmail.com] Sent: Friday, February 26, 2010 7:50 AM To: users@wicket.apache.org Subject: Re: UI Layout For me it seems it would very confusing if I only had one page. I'd prefer pages that are target against their specific functionality, keeping code simpler. I'd still be using panels though, giving the benefit of ajax, role base plus all the other stuff. my 2 centavos -Nino 2010/2/26 Josh Kamau joshnet2...@gmail.com Wicket offers high level of flexibility when it comes to page layout. So i ask, what are the best practices? is it ok if i use panels only and one main layout page? Kind regards Josh. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UI Layout
) ); } abstract protected Panel createPanel_A( String panelWicketID ); abstract protected Panel createPanel_B( String panelWicketID ); } Concrete child pages would look something like this: public class OneConcreteChildPage extends MyApplicationBasePage { protected Panel createPanel_A( String panelWicketID ) { return new WhateverPanel(panelWicketID,...); } protected Panel createPanel_B( String panelWicketID ) { return new SomeOtherPanelType(panelWicketID, ...); } } This can be generalized in that the application base page can have however many component-defining abstract methods you please. Furthermore, one can generalize this to a page hierarchy of any depth, since a semi-base page can define additional abstract methods to be called by its implementation of createPanel_A() or createPanel_B(). -Frank -Original Message- From: nino martinez wael [mailto:nino.martinez.w...@gmail.com] Sent: Friday, February 26, 2010 7:50 AM To: users@wicket.apache.org Subject: Re: UI Layout For me it seems it would very confusing if I only had one page. I'd prefer pages that are target against their specific functionality, keeping code simpler. I'd still be using panels though, giving the benefit of ajax, role base plus all the other stuff. my 2 centavos -Nino 2010/2/26 Josh Kamau joshnet2...@gmail.com Wicket offers high level of flexibility when it comes to page layout. So i ask, what are the best practices? is it ok if i use panels only and one main layout page? Kind regards Josh. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UI Layout
DelayedAssemblyWebPage { protected void assembleComponents() throws Exception { // Add some components. // Panels to be defined in subclasses are added // by calling: // // add( createPanel_A(a_wicket_id) ); // // and // // add( createPanel_B(some_other_wicket_id) ); } abstract protected Panel createPanel_A( String panelWicketID ); abstract protected Panel createPanel_B( String panelWicketID ); } Concrete child pages would look something like this: public class OneConcreteChildPage extends MyApplicationBasePage { protected Panel createPanel_A( String panelWicketID ) { return new WhateverPanel(panelWicketID,...); } protected Panel createPanel_B( String panelWicketID ) { return new SomeOtherPanelType(panelWicketID, ...); } } This can be generalized in that the application base page can have however many component-defining abstract methods you please. Furthermore, one can generalize this to a page hierarchy of any depth, since a semi-base page can define additional abstract methods to be called by its implementation of createPanel_A() or createPanel_B(). -Frank -Original Message- From: nino martinez wael [mailto:nino.martinez.w...@gmail.com] Sent: Friday, February 26, 2010 7:50 AM To: users@wicket.apache.org Subject: Re: UI Layout For me it seems it would very confusing if I only had one page. I'd prefer pages that are target against their specific functionality, keeping code simpler. I'd still be using panels though, giving the benefit of ajax, role base plus all the other stuff. my 2 centavos -Nino 2010/2/26 Josh Kamau joshnet2...@gmail.com Wicket offers high level of flexibility when it comes to page layout. So i ask, what are the best practices? is it ok if i use panels only and one main layout page? Kind regards Josh. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Marek Šabo Server Manager Club SU CVUT Buben Bubenečská Kolej (421) XMPP: zeratul...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UI Layout
+1 for multiple page + abstract base page.. 2010/2/26 Frank Silbermann frank.silberm...@fedex.com Single page versus multi-page application? Some people build a single-page application in which panels are replaced dynamically. With this approach, the single page is analogous to a Swing JFrame, to whom components are added and removed (or made visible or invisible as needed). Many people prefer to have separate pages for different functionality -- and this is necessary if the user is to be able to bookmark several different pages. To do this, many people use markup inheritance, in which sub-pages inherit from the base page, and the sub-page mark-up is combined with the base-page mark-up. (Though it is to be generalized in the future, I believe currently there can be only a single place in the base page where the sub-page's components can go.) I prefer to use a base page which contains one or more panels to be defined by the sub-pages, via abstract panel-creation methods called by the base page. However, Wicket convention is to add components in the page constructor, and calling an overridden method from a constructor is bad. (The overridden method will not be able to use anything set up in the sub-page's constructor, due to the order in which constructors are called.) I solve this problem by making my base pages inherit from the following: public class DelayedAssemblyWebPage extends WebPage { protected boolean componentsAssembled = false; @Override protected void onBeforeRender() { if ( !componentsAssembled ) { try { assembleComponents(); componentsAssembled = true; } catch (Exception e) { throw new RuntimeException(e); } } super.onBeforeRender(); } abstract protected void assembleComponents() throws Exception {} } So my application base page would look something like this: public class MyApplicationBasePage extends DelayedAssemblyWebPage { protected void assembleComponents() throws Exception { // Add some components. // Panels to be defined in subclasses are added // by calling: // // add( createPanel_A(a_wicket_id) ); // // and // // add( createPanel_B(some_other_wicket_id) ); } abstract protected Panel createPanel_A( String panelWicketID ); abstract protected Panel createPanel_B( String panelWicketID ); } Concrete child pages would look something like this: public class OneConcreteChildPage extends MyApplicationBasePage { protected Panel createPanel_A( String panelWicketID ) { return new WhateverPanel(panelWicketID,...); } protected Panel createPanel_B( String panelWicketID ) { return new SomeOtherPanelType(panelWicketID, ...); } } This can be generalized in that the application base page can have however many component-defining abstract methods you please. Furthermore, one can generalize this to a page hierarchy of any depth, since a semi-base page can define additional abstract methods to be called by its implementation of createPanel_A() or createPanel_B(). -Frank -Original Message- From: nino martinez wael [mailto:nino.martinez.w...@gmail.com] Sent: Friday, February 26, 2010 7:50 AM To: users@wicket.apache.org Subject: Re: UI Layout For me it seems it would very confusing if I only had one page. I'd prefer pages that are target against their specific functionality, keeping code simpler. I'd still be using panels though, giving the benefit of ajax, role base plus all the other stuff. my 2 centavos -Nino 2010/2/26 Josh Kamau joshnet2...@gmail.com Wicket offers high level of flexibility when it comes to page layout. So i ask, what are the best practices? is it ok if i use panels only and one main layout page? Kind regards Josh.
Re: UI Layout
Right now I'm developing a single-page-multi-panel application. Had some issues regarding history (that is browser back/forward), but succeeded to fix them using wicketstuff-ajaxhistory. What I failed (not yet succeded ...) is related to 'deep links', that is to bookmarkable URLs. All in all, an Ajax based approach seeems to be more promising (on long term) than the classical multi-page based one. Stefan --- On Fri, 2/26/10, Josh Kamau joshnet2...@gmail.com wrote: From: Josh Kamau joshnet2...@gmail.com Subject: UI Layout To: users@wicket.apache.org Date: Friday, February 26, 2010, 12:23 PM Wicket offers high level of flexibility when it comes to page layout. So i ask, what are the best practices? is it ok if i use panels only and one main layout page? Kind regards Josh. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UI Layout
For me it seems it would very confusing if I only had one page. I'd prefer pages that are target against their specific functionality, keeping code simpler. I'd still be using panels though, giving the benefit of ajax, role base plus all the other stuff. my 2 centavos -Nino 2010/2/26 Josh Kamau joshnet2...@gmail.com Wicket offers high level of flexibility when it comes to page layout. So i ask, what are the best practices? is it ok if i use panels only and one main layout page? Kind regards Josh.
RE: UI Layout
Single page versus multi-page application? Some people build a single-page application in which panels are replaced dynamically. With this approach, the single page is analogous to a Swing JFrame, to whom components are added and removed (or made visible or invisible as needed). Many people prefer to have separate pages for different functionality -- and this is necessary if the user is to be able to bookmark several different pages. To do this, many people use markup inheritance, in which sub-pages inherit from the base page, and the sub-page mark-up is combined with the base-page mark-up. (Though it is to be generalized in the future, I believe currently there can be only a single place in the base page where the sub-page's components can go.) I prefer to use a base page which contains one or more panels to be defined by the sub-pages, via abstract panel-creation methods called by the base page. However, Wicket convention is to add components in the page constructor, and calling an overridden method from a constructor is bad. (The overridden method will not be able to use anything set up in the sub-page's constructor, due to the order in which constructors are called.) I solve this problem by making my base pages inherit from the following: public class DelayedAssemblyWebPage extends WebPage { protected boolean componentsAssembled = false; @Override protected void onBeforeRender() { if ( !componentsAssembled ) { try { assembleComponents(); componentsAssembled = true; } catch (Exception e) { throw new RuntimeException(e); } } super.onBeforeRender(); } abstract protected void assembleComponents() throws Exception {} } So my application base page would look something like this: public class MyApplicationBasePage extends DelayedAssemblyWebPage { protected void assembleComponents() throws Exception { // Add some components. // Panels to be defined in subclasses are added // by calling: // // add( createPanel_A(a_wicket_id) ); // // and // // add( createPanel_B(some_other_wicket_id) ); } abstract protected Panel createPanel_A( String panelWicketID ); abstract protected Panel createPanel_B( String panelWicketID ); } Concrete child pages would look something like this: public class OneConcreteChildPage extends MyApplicationBasePage { protected Panel createPanel_A( String panelWicketID ) { return new WhateverPanel(panelWicketID,...); } protected Panel createPanel_B( String panelWicketID ) { return new SomeOtherPanelType(panelWicketID, ...); } } This can be generalized in that the application base page can have however many component-defining abstract methods you please. Furthermore, one can generalize this to a page hierarchy of any depth, since a semi-base page can define additional abstract methods to be called by its implementation of createPanel_A() or createPanel_B(). -Frank -Original Message- From: nino martinez wael [mailto:nino.martinez.w...@gmail.com] Sent: Friday, February 26, 2010 7:50 AM To: users@wicket.apache.org Subject: Re: UI Layout For me it seems it would very confusing if I only had one page. I'd prefer pages that are target against their specific functionality, keeping code simpler. I'd still be using panels though, giving the benefit of ajax, role base plus all the other stuff. my 2 centavos -Nino 2010/2/26 Josh Kamau joshnet2...@gmail.com Wicket offers high level of flexibility when it comes to page layout. So i ask, what are the best practices? is it ok if i use panels only and one main layout page? Kind regards Josh.
Re: UI Layout
Hi! I would propose using mashup approach, it's more flexible you don't need abstract factory methods for adding content: http://code.google.com/p/wicket-mashup/ ** Martin 2010/2/26 Frank Silbermann frank.silberm...@fedex.com: Single page versus multi-page application? Some people build a single-page application in which panels are replaced dynamically. With this approach, the single page is analogous to a Swing JFrame, to whom components are added and removed (or made visible or invisible as needed). Many people prefer to have separate pages for different functionality -- and this is necessary if the user is to be able to bookmark several different pages. To do this, many people use markup inheritance, in which sub-pages inherit from the base page, and the sub-page mark-up is combined with the base-page mark-up. (Though it is to be generalized in the future, I believe currently there can be only a single place in the base page where the sub-page's components can go.) I prefer to use a base page which contains one or more panels to be defined by the sub-pages, via abstract panel-creation methods called by the base page. However, Wicket convention is to add components in the page constructor, and calling an overridden method from a constructor is bad. (The overridden method will not be able to use anything set up in the sub-page's constructor, due to the order in which constructors are called.) I solve this problem by making my base pages inherit from the following: public class DelayedAssemblyWebPage extends WebPage { protected boolean componentsAssembled = false; �...@override protected void onBeforeRender() { if ( !componentsAssembled ) { try { assembleComponents(); componentsAssembled = true; } catch (Exception e) { throw new RuntimeException(e); } } super.onBeforeRender(); } abstract protected void assembleComponents() throws Exception {} } So my application base page would look something like this: public class MyApplicationBasePage extends DelayedAssemblyWebPage { protected void assembleComponents() throws Exception { // Add some components. // Panels to be defined in subclasses are added // by calling: // // add( createPanel_A(a_wicket_id) ); // // and // // add( createPanel_B(some_other_wicket_id) ); } abstract protected Panel createPanel_A( String panelWicketID ); abstract protected Panel createPanel_B( String panelWicketID ); } Concrete child pages would look something like this: public class OneConcreteChildPage extends MyApplicationBasePage { protected Panel createPanel_A( String panelWicketID ) { return new WhateverPanel(panelWicketID,...); } protected Panel createPanel_B( String panelWicketID ) { return new SomeOtherPanelType(panelWicketID, ...); } } This can be generalized in that the application base page can have however many component-defining abstract methods you please. Furthermore, one can generalize this to a page hierarchy of any depth, since a semi-base page can define additional abstract methods to be called by its implementation of createPanel_A() or createPanel_B(). -Frank -Original Message- From: nino martinez wael [mailto:nino.martinez.w...@gmail.com] Sent: Friday, February 26, 2010 7:50 AM To: users@wicket.apache.org Subject: Re: UI Layout For me it seems it would very confusing if I only had one page. I'd prefer pages that are target against their specific functionality, keeping code simpler. I'd still be using panels though, giving the benefit of ajax, role base plus all the other stuff. my 2 centavos -Nino 2010/2/26 Josh Kamau joshnet2...@gmail.com Wicket offers high level of flexibility when it comes to page layout. So i ask, what are the best practices? is it ok if i use panels only and one main layout page? Kind regards Josh. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org