You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by ha...@dds.nl on 2011/04/06 11:09:58 UTC
Wiquery experiences
Hi,
We are thinking of using wiquery for a project. We are interested in
the experiences of people using it. Does wiquery work in the major
browsers (IE7, IE8, IE9, FF3 and Chrome)? Are there any complications
when different versions of jquery are used on other places in the
HTML? What is the version of Wicket you used it?
Please share your experiences.
Thanks in advance,
Haiko van der Schaaf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wiquery experiences
Posted by Maarten Billemont <lh...@gmail.com>.
On 07 Apr 2011, at 09:54, Hielke Hoeve wrote:
> Maarten says:
> Writing what should be JavaScript in your wicket Java code is quite out-of-place, and generally all you need to do is place your code where it belongs, in a .js or your markup.
>
> I wonder if he ever really used WiQuery or even looked how it's used. Or for that matter used jQuery. What you *don't* need to do with WiQuery is write js code in your java classes and we recommend to put all js code in js files and load them as a resource!
When I said "Writing what *should* be JavaScript in your wicket Java code ...", what I was referring to is things like (ref. wiQuery Quickstart):
JsScope.quickScope("alert('foo')");
to represent:
function() {
alert('foo');
}
Don't get me wrong, I'm sure wiQuery has its place and use. As I said, tightly integrating jQuery components with your Wicket application logic is probably much easier done with this abstraction layer.
It's just important to know that wiQuery isn't a requirement for being able to do jQuery in a wicket application, or any sort of custom JS/AJAX for that matter. And if wiQuery has indeed matured a lot, and you aren't at risk of code injection, then sure, have at it - where it makes sense.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wiquery experiences
Posted by Ioannis Canellos <io...@gmail.com>.
The best thing to do is use the right tool for the right job. I personally
use both plain jquery and wiquery and I am happy with it.
On Thu, Apr 7, 2011 at 10:54 AM, Hielke Hoeve <Hi...@topicus.nl>wrote:
> WiQuery *has* matured a lot. We are working hard in our late hours to
> implement and test interfaces to all facets of jQuery and are getting ready
> for Wicket 1.5.
>
> Bruno is right that for some purposes it is easy using only jQuery, simply
> add the jQuery js files you want and write a script tag with the
> document.onready function. But I am curious how one handles ajax added
> panels with jQuery functionality on a page or components that consume data
> or jquery enabled components that have jQuery options set based on business
> logic or components that have their visibility set based on business logic.
> Once a component is replaced by an ajax call the jQuery functionality is
> removed from this component. Not to speak of being able to reuse numerous
> components on numerous pages... I don't even want to begin to think about
> how to handle jquery component options based on business data.
>
> Now I do agree that in some cases (which do not cover the ones I described
> above) WiQuery is absolutely not useful and a simple static js file and
> static jQuery initialization statement is good enough. Not every jQuery
> component is worth converting to a WiQuery component. The ones that are
> worth are often:
> - components that are ajax enabled and/or;
> - components that have their jQuery options depend on data or logic and/or;
> - components that have their visibility or are enabled based on data or
> logic and/or;
> - components that are added by an ajax request and not at page load;
>
>
> The reason I started working on the WiQuery project is because my company
> creates enterprise administration applications where we have *a lot* of
> pages with ajax replaced panels, autocomplete text fields, accordion panels,
> tabbed panels, feedback popups... you name it we have it.
> With WiQuery we create reusable components, define which resources this
> component needs and what bit of jQuery it needs to initialize after the page
> (or ajax response) has been loaded, and simple add them to the page. The
> page is on a need to know basis, it will define the layout not boss all
> components around... WiQuery checks which resources are loaded, removes
> duplicates, adds the jQuery Core, jQuery UI and jQuery UI Theme. While
> managing multiple projects with over 1000+ pages, this takes away quite a
> load off our shoulders.
>
> Maarten says:
> Writing what should be JavaScript in your wicket Java code is quite
> out-of-place, and generally all you need to do is place your code where it
> belongs, in a .js or your markup.
>
> I wonder if he ever really used WiQuery or even looked how it's used. Or
> for that matter used jQuery. What you *don't* need to do with WiQuery is
> write js code in your java classes and we recommend to put all js code in js
> files and load them as a resource! To create a jQuery wicket component you:
> - write your jQuery js file and the html file that comes with it;
> - write the java code that you need to insert any application data,
> behaviors or validators;
> - let your component implement an interface (so WiQuery can detect it upon
> creation) to define which js/css files you want to be added as a resource
> and define the jQuery initialization statement with java code (which is
> translated most often something like "document.onready(.....);".
>
>
> There are other libraries around that do about the same as WiQuery, and
> perhaps better or faster, but my rant above is to clarify why the project
> exists and why people are using it. And the best part of it is: you don't
> have to use it...
>
> Regards,
>
> Hielke
>
> -----Original Message-----
> From: Bruno Borges [mailto:bruno.borges@gmail.com]
> Sent: donderdag 7 april 2011 0:32
> To: users@wicket.apache.org
> Cc: Maarten Billemont
> Subject: Re: Wiquery experiences
>
> Most of the things you want to do with jQuery, you don't need a library
> for.
>
> I totally agree with Maarten
>
>
> Bruno Borges
> www.brunoborges.com.br
> +55 21 76727099
>
> "The glory of great men should always be measured by the means they have
> used to acquire it."
> - Francois de La Rochefoucauld
>
>
>
> On Wed, Apr 6, 2011 at 6:15 AM, Maarten Billemont <lh...@gmail.com>
> wrote:
>
> > Unless WiQuery has matured a *lot* lately and the code has been
> > cleaned up significantly, I can't recommend it, personally.
> >
> > Writing what should be JavaScript in your wicket Java code is quite
> > out-of-place, and generally all you need to do is place your code
> > where it belongs, in a .js or your markup.
> >
> > There may be some odd cases here or there where tighter integration of
> > jQuery and Wicket can be beneficial, but those can usually be resolved
> > some other way.
> >
> > I don't have enough experience or knowledge of the framework to cast a
> > final vote though, all I'm saying is: beware of the quality of this
> > library's code and make sure you actually need it first (I want to do
> > jQuery stuff in my Wicket application is generally not reason enough).
> >
> > On 06 Apr 2011, at 11:09, haiko@dds.nl wrote:
> >
> > > Hi,
> > >
> > > We are thinking of using wiquery for a project. We are interested in
> > > the
> > experiences of people using it. Does wiquery work in the major
> > browsers (IE7, IE8, IE9, FF3 and Chrome)? Are there any complications
> > when different versions of jquery are used on other places in the
> > HTML? What is the version of Wicket you used it?
> > >
> > > Please share your experiences.
> > >
> > > Thanks in advance,
> > >
> > > Haiko van der Schaaf
> > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
--
*Ioannis Canellos*
*
http://iocanel.blogspot.com
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
*
RE: Wiquery experiences
Posted by Hielke Hoeve <Hi...@topicus.nl>.
>-----Original Message-----
>From: joseph.pachod@gmail.com [mailto:joseph.pachod@gmail.com] On
Behalf Of Live Nono
>Sent: donderdag 7 april 2011 13:47
>To: users@wicket.apache.org
>Subject: Re: Wiquery experiences
>- does wiquery support being used from a wicket ajax request nicely?
Yes! This is the main aim of WiQuery, if an component is ajax refreshed
it is replaced (or added for the first time because it was previously
invisible) in the DOM tree there by removing any jQuery functionality.
WiQuery will add all jQuery functionality again.
> If so, is it part of its "intended aims" and thus made across all its
wrappers or just some of the wrapper being properly done? How does it
handle the case of WiQuery dependent component made visible through an
ajax request? => Hielke already provided some answers which I'm glad to
have read, but it doesn't cover it all.
What do you mean by wrappers? In order for WiQuery to do its job a
component needs to implement an interface in order to be detected by
WiQuery. This is done through Wickets component initialization
listeners. If a component is not visible, the resources and js code is
not used by WiQuery. Once the component is visible (again) on the page
the resources and js code will be used by WiQuery.
>- ease to use with other libraries, like JSLibraries (and its CDN
integration) ?
WiQuery does not provide any java script utils like jQuery does. It does
have js files, but these are files that are component specific. WiQuery
itself will not conflict with JavaScript libraries, unless jQuery does.
> reliability now and in the future: what about eventual bug I would
find, would they be easy to fix on my own? Does the code make enough
sense to me? In there a proper community around to help in case ?
What's the plan for currently supported jquery versions and the future?
=> Ernesto also provided some answers, which is good, thanks
Issues can be reported on our google project site[1]. We have a google
group[2] where any question about WiQuery can be asked and all are
answered (at least that is what we strive for). If you have questions
about an official wiquery plugin[3] questions can be asked in that
corresponding google group[4].
If you still have any questions, ask here or in the wiquery google
group[2].
Hielke
[1] http://code.google.com/p/wiquery/issues/list
[2] http://groups.google.com/group/wiquery
[3] http://code.google.com/p/wiquery-plugins/
[4] http://groups.google.com/group/wiquery-plugins
-----Original Message-----
From: joseph.pachod@gmail.com [mailto:joseph.pachod@gmail.com] On Behalf
Of Live Nono
Sent: donderdag 7 april 2011 13:47
To: users@wicket.apache.org
Subject: Re: Wiquery experiences
Ernesto, Hielke
thanks a lot for your answers
At the time I looked at wiquery, it was for some specific task. This
task didn't include explorating whether a full blown jquery/wicket
integration framework would fit our needs. This is quite a task on its
own imho, and there the lack of documentation is a real issue.
For example, questions I had which would involve quite some time to
figure out:
- does wiquery support being used from a wicket ajax request nicely?
If so, is it part of its "intended aims" and thus made across all its
wrappers or just some of the wrapper being properly done? How does it
handle the case of wiquery dependent component made visible through an
ajax request? => Hielke already provided some answers which I'm glad to
have read, but it doesn't cover it all
- ease to use with other librairies, like JSLibraries (and its CDN
integration) ?
- reliability now and in the future: what about eventual bug I would
find, would they be easy to fix on my own? Does the code make enough
sense to me? In there a proper community around to help in case ?
What's the plan for currently supported jquery versions and the future?
=> Ernesto also provided some answers, which is good, thanks
:)
I hope you understand better the questions which arise and why it would
take a while to figure them out just by looking at the code.
That's where more documentation/tutorial/feedbacks would help, to make
the discovery cost lower.
as a side note, I was already bitten by being early adopting some new
frameworks, so now I tend to be more carefull, esp. for stuff that are
directly seen by the users...
regards
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wiquery experiences
Posted by Live Nono <li...@gmail.com>.
Ernesto, Hielke
thanks a lot for your answers
At the time I looked at wiquery, it was for some specific task. This
task didn't include explorating whether a full blown jquery/wicket
integration framework would fit our needs. This is quite a task on its
own imho, and there the lack of documentation is a real issue.
For example, questions I had which would involve quite some time to figure out:
- does wiquery support being used from a wicket ajax request nicely?
If so, is it part of its "intended aims" and thus made across all its
wrappers or just some of the wrapper being properly done? How does it
handle the case of wiquery dependent component made visible through an
ajax request? => Hielke already provided some answers which I'm glad
to have read, but it doesn't cover it all
- ease to use with other librairies, like JSLibraries (and its CDN
integration) ?
- reliability now and in the future: what about eventual bug I would
find, would they be easy to fix on my own? Does the code make enough
sense to me? In there a proper community around to help in case ?
What's the plan for currently supported jquery versions and the
future? => Ernesto also provided some answers, which is good, thanks
:)
I hope you understand better the questions which arise and why it
would take a while to figure them out just by looking at the code.
That's where more documentation/tutorial/feedbacks would help, to make
the discovery cost lower.
as a side note, I was already bitten by being early adopting some new
frameworks, so now I tend to be more carefull, esp. for stuff that are
directly seen by the users...
regards
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Wiquery experiences
Posted by Hielke Hoeve <Hi...@topicus.nl>.
The wiki is quite outdated, except for a small and somewhat hidden area: http://code.google.com/p/wiquery/wiki/QuickStart
The WiQuery plugins project isn't really well known and our project site does not point to it, but it a good start to see how applications can be converted, as it also contains a simple WebApplication.
Any other pointers as how to improve documentation and tutorials are most welcome!
Hielke
-----Original Message-----
From: Ernesto Reinaldo Barreiro [mailto:reiern70@gmail.com]
Sent: donderdag 7 april 2011 12:26
To: users@wicket.apache.org
Subject: Re: Wiquery experiences
Joseph,
Well it is true the documentation is not updated and there is not much to start with... but mind that WiQuery is maintained by people that do this mostly on their free time... I think
1- support on the google group is rather good
2- the speed on fixing bugs and reacting to user input is hight...
Additionally some of use have tried to add some extensions integrating different jquery plugins (components) (e.g. see [1] and [2]).
So, what else do you need? Someone to teach you step by step how to use the projects? What about getting the example project, see how the examples works, look to the source code... and learn from there? IMHO theses are basic skills someone trying to make a living as Java programmer should have... and once you have learned something... Why not take your time and contribute some documentation?
Regards,
Ernesto
References,
1-http://code.google.com/p/wiquery-plugins/
2-https://github.com/hielkehoeve/wiquery-jqplot
On Thu, Apr 7, 2011 at 12:06 PM, Live Nono <li...@gmail.com> wrote:
> Hi Hielke
>
> Nice to be able to discuss with some wiquery commiter.
>
> Acutally, I was willing to use it some time ago but I found wiquery
> wasn't very good at selling itself. The wiki is pretty old and useless
> (http://code.google.com/p/wiquery/wiki/DocumentationHome?tm=6) and at
> the time I found no tutorial or example... Did it change in some way?
> I would still love to be able to have a better clue of it, since it
> looks intriguing, but I don't have enough time to do a proper
> investigation on how to use it...
>
> Regards
>
> 2011/4/7 Hielke Hoeve <Hi...@topicus.nl>:
>> WiQuery *has* matured a lot. We are working hard in our late hours to implement and test interfaces to all facets of jQuery and are getting ready for Wicket 1.5.
>>
>> Bruno is right that for some purposes it is easy using only jQuery, simply add the jQuery js files you want and write a script tag with the document.onready function. But I am curious how one handles ajax added panels with jQuery functionality on a page or components that consume data or jquery enabled components that have jQuery options set based on business logic or components that have their visibility set based on business logic. Once a component is replaced by an ajax call the jQuery functionality is removed from this component. Not to speak of being able to reuse numerous components on numerous pages... I don't even want to begin to think about how to handle jquery component options based on business data.
>>
>> Now I do agree that in some cases (which do not cover the ones I described above) WiQuery is absolutely not useful and a simple static js file and static jQuery initialization statement is good enough. Not every jQuery component is worth converting to a WiQuery component. The ones that are worth are often:
>> - components that are ajax enabled and/or;
>> - components that have their jQuery options depend on data or logic
>> and/or;
>> - components that have their visibility or are enabled based on data
>> or logic and/or;
>> - components that are added by an ajax request and not at page load;
>>
>>
>> The reason I started working on the WiQuery project is because my company creates enterprise administration applications where we have *a lot* of pages with ajax replaced panels, autocomplete text fields, accordion panels, tabbed panels, feedback popups... you name it we have it.
>> With WiQuery we create reusable components, define which resources this component needs and what bit of jQuery it needs to initialize after the page (or ajax response) has been loaded, and simple add them to the page. The page is on a need to know basis, it will define the layout not boss all components around... WiQuery checks which resources are loaded, removes duplicates, adds the jQuery Core, jQuery UI and jQuery UI Theme. While managing multiple projects with over 1000+ pages, this takes away quite a load off our shoulders.
>>
>> Maarten says:
>> Writing what should be JavaScript in your wicket Java code is quite out-of-place, and generally all you need to do is place your code where it belongs, in a .js or your markup.
>>
>> I wonder if he ever really used WiQuery or even looked how it's used. Or for that matter used jQuery. What you *don't* need to do with WiQuery is write js code in your java classes and we recommend to put all js code in js files and load them as a resource! To create a jQuery wicket component you:
>> - write your jQuery js file and the html file that comes with it;
>> - write the java code that you need to insert any application data,
>> behaviors or validators;
>> - let your component implement an interface (so WiQuery can detect it upon creation) to define which js/css files you want to be added as a resource and define the jQuery initialization statement with java code (which is translated most often something like "document.onready(.....);".
>>
>>
>> There are other libraries around that do about the same as WiQuery, and perhaps better or faster, but my rant above is to clarify why the project exists and why people are using it. And the best part of it is: you don't have to use it...
>>
>> Regards,
>>
>> Hielke
>>
>> -----Original Message-----
>> From: Bruno Borges [mailto:bruno.borges@gmail.com]
>> Sent: donderdag 7 april 2011 0:32
>> To: users@wicket.apache.org
>> Cc: Maarten Billemont
>> Subject: Re: Wiquery experiences
>>
>> Most of the things you want to do with jQuery, you don't need a library for.
>>
>> I totally agree with Maarten
>>
>>
>> Bruno Borges
>> www.brunoborges.com.br
>> +55 21 76727099
>>
>> "The glory of great men should always be measured by the means they have used to acquire it."
>> - Francois de La Rochefoucauld
>>
>>
>>
>> On Wed, Apr 6, 2011 at 6:15 AM, Maarten Billemont <lh...@gmail.com> wrote:
>>
>>> Unless WiQuery has matured a *lot* lately and the code has been
>>> cleaned up significantly, I can't recommend it, personally.
>>>
>>> Writing what should be JavaScript in your wicket Java code is quite
>>> out-of-place, and generally all you need to do is place your code
>>> where it belongs, in a .js or your markup.
>>>
>>> There may be some odd cases here or there where tighter integration
>>> of jQuery and Wicket can be beneficial, but those can usually be
>>> resolved some other way.
>>>
>>> I don't have enough experience or knowledge of the framework to cast
>>> a final vote though, all I'm saying is: beware of the quality of
>>> this library's code and make sure you actually need it first (I want
>>> to do jQuery stuff in my Wicket application is generally not reason enough).
>>>
>>> On 06 Apr 2011, at 11:09, haiko@dds.nl wrote:
>>>
>>> > Hi,
>>> >
>>> > We are thinking of using wiquery for a project. We are interested
>>> > in the
>>> experiences of people using it. Does wiquery work in the major
>>> browsers (IE7, IE8, IE9, FF3 and Chrome)? Are there any
>>> complications when different versions of jquery are used on other
>>> places in the HTML? What is the version of Wicket you used it?
>>> >
>>> > Please share your experiences.
>>> >
>>> > Thanks in advance,
>>> >
>>> > Haiko van der Schaaf
>>> >
>>> >
>>> > ------------------------------------------------------------------
>>> > --
>>> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>> >
>>>
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wiquery experiences
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
Joseph,
Well it is true the documentation is not updated and there is not much
to start with... but mind that WiQuery is maintained by people that do
this mostly on their free time... I think
1- support on the google group is rather good
2- the speed on fixing bugs and reacting to user input is hight...
Additionally some of use have tried to add some extensions integrating
different jquery plugins (components) (e.g. see [1] and [2]).
So, what else do you need? Someone to teach you step by step how to
use the projects? What about getting the example project, see how the
examples works, look to the source code... and learn from there? IMHO
theses are basic skills someone trying to make a living as Java
programmer should have... and once you have learned something... Why
not take your time and contribute some documentation?
Regards,
Ernesto
References,
1-http://code.google.com/p/wiquery-plugins/
2-https://github.com/hielkehoeve/wiquery-jqplot
On Thu, Apr 7, 2011 at 12:06 PM, Live Nono <li...@gmail.com> wrote:
> Hi Hielke
>
> Nice to be able to discuss with some wiquery commiter.
>
> Acutally, I was willing to use it some time ago but I found wiquery
> wasn't very good at selling itself. The wiki is pretty old and useless
> (http://code.google.com/p/wiquery/wiki/DocumentationHome?tm=6) and at
> the time I found no tutorial or example... Did it change in some way?
> I would still love to be able to have a better clue of it, since it
> looks intriguing, but I don't have enough time to do a proper
> investigation on how to use it...
>
> Regards
>
> 2011/4/7 Hielke Hoeve <Hi...@topicus.nl>:
>> WiQuery *has* matured a lot. We are working hard in our late hours to implement and test interfaces to all facets of jQuery and are getting ready for Wicket 1.5.
>>
>> Bruno is right that for some purposes it is easy using only jQuery, simply add the jQuery js files you want and write a script tag with the document.onready function. But I am curious how one handles ajax added panels with jQuery functionality on a page or components that consume data or jquery enabled components that have jQuery options set based on business logic or components that have their visibility set based on business logic. Once a component is replaced by an ajax call the jQuery functionality is removed from this component. Not to speak of being able to reuse numerous components on numerous pages... I don't even want to begin to think about how to handle jquery component options based on business data.
>>
>> Now I do agree that in some cases (which do not cover the ones I described above) WiQuery is absolutely not useful and a simple static js file and static jQuery initialization statement is good enough. Not every jQuery component is worth converting to a WiQuery component. The ones that are worth are often:
>> - components that are ajax enabled and/or;
>> - components that have their jQuery options depend on data or logic and/or;
>> - components that have their visibility or are enabled based on data or logic and/or;
>> - components that are added by an ajax request and not at page load;
>>
>>
>> The reason I started working on the WiQuery project is because my company creates enterprise administration applications where we have *a lot* of pages with ajax replaced panels, autocomplete text fields, accordion panels, tabbed panels, feedback popups... you name it we have it.
>> With WiQuery we create reusable components, define which resources this component needs and what bit of jQuery it needs to initialize after the page (or ajax response) has been loaded, and simple add them to the page. The page is on a need to know basis, it will define the layout not boss all components around... WiQuery checks which resources are loaded, removes duplicates, adds the jQuery Core, jQuery UI and jQuery UI Theme. While managing multiple projects with over 1000+ pages, this takes away quite a load off our shoulders.
>>
>> Maarten says:
>> Writing what should be JavaScript in your wicket Java code is quite out-of-place, and generally all you need to do is place your code where it belongs, in a .js or your markup.
>>
>> I wonder if he ever really used WiQuery or even looked how it's used. Or for that matter used jQuery. What you *don't* need to do with WiQuery is write js code in your java classes and we recommend to put all js code in js files and load them as a resource! To create a jQuery wicket component you:
>> - write your jQuery js file and the html file that comes with it;
>> - write the java code that you need to insert any application data, behaviors or validators;
>> - let your component implement an interface (so WiQuery can detect it upon creation) to define which js/css files you want to be added as a resource and define the jQuery initialization statement with java code (which is translated most often something like "document.onready(.....);".
>>
>>
>> There are other libraries around that do about the same as WiQuery, and perhaps better or faster, but my rant above is to clarify why the project exists and why people are using it. And the best part of it is: you don't have to use it...
>>
>> Regards,
>>
>> Hielke
>>
>> -----Original Message-----
>> From: Bruno Borges [mailto:bruno.borges@gmail.com]
>> Sent: donderdag 7 april 2011 0:32
>> To: users@wicket.apache.org
>> Cc: Maarten Billemont
>> Subject: Re: Wiquery experiences
>>
>> Most of the things you want to do with jQuery, you don't need a library for.
>>
>> I totally agree with Maarten
>>
>>
>> Bruno Borges
>> www.brunoborges.com.br
>> +55 21 76727099
>>
>> "The glory of great men should always be measured by the means they have used to acquire it."
>> - Francois de La Rochefoucauld
>>
>>
>>
>> On Wed, Apr 6, 2011 at 6:15 AM, Maarten Billemont <lh...@gmail.com> wrote:
>>
>>> Unless WiQuery has matured a *lot* lately and the code has been
>>> cleaned up significantly, I can't recommend it, personally.
>>>
>>> Writing what should be JavaScript in your wicket Java code is quite
>>> out-of-place, and generally all you need to do is place your code
>>> where it belongs, in a .js or your markup.
>>>
>>> There may be some odd cases here or there where tighter integration of
>>> jQuery and Wicket can be beneficial, but those can usually be resolved
>>> some other way.
>>>
>>> I don't have enough experience or knowledge of the framework to cast a
>>> final vote though, all I'm saying is: beware of the quality of this
>>> library's code and make sure you actually need it first (I want to do
>>> jQuery stuff in my Wicket application is generally not reason enough).
>>>
>>> On 06 Apr 2011, at 11:09, haiko@dds.nl wrote:
>>>
>>> > Hi,
>>> >
>>> > We are thinking of using wiquery for a project. We are interested in
>>> > the
>>> experiences of people using it. Does wiquery work in the major
>>> browsers (IE7, IE8, IE9, FF3 and Chrome)? Are there any complications
>>> when different versions of jquery are used on other places in the
>>> HTML? What is the version of Wicket you used it?
>>> >
>>> > Please share your experiences.
>>> >
>>> > Thanks in advance,
>>> >
>>> > Haiko van der Schaaf
>>> >
>>> >
>>> > --------------------------------------------------------------------
>>> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wiquery experiences
Posted by Live Nono <li...@gmail.com>.
Hi Hielke
Nice to be able to discuss with some wiquery commiter.
Acutally, I was willing to use it some time ago but I found wiquery
wasn't very good at selling itself. The wiki is pretty old and useless
(http://code.google.com/p/wiquery/wiki/DocumentationHome?tm=6) and at
the time I found no tutorial or example... Did it change in some way?
I would still love to be able to have a better clue of it, since it
looks intriguing, but I don't have enough time to do a proper
investigation on how to use it...
Regards
2011/4/7 Hielke Hoeve <Hi...@topicus.nl>:
> WiQuery *has* matured a lot. We are working hard in our late hours to implement and test interfaces to all facets of jQuery and are getting ready for Wicket 1.5.
>
> Bruno is right that for some purposes it is easy using only jQuery, simply add the jQuery js files you want and write a script tag with the document.onready function. But I am curious how one handles ajax added panels with jQuery functionality on a page or components that consume data or jquery enabled components that have jQuery options set based on business logic or components that have their visibility set based on business logic. Once a component is replaced by an ajax call the jQuery functionality is removed from this component. Not to speak of being able to reuse numerous components on numerous pages... I don't even want to begin to think about how to handle jquery component options based on business data.
>
> Now I do agree that in some cases (which do not cover the ones I described above) WiQuery is absolutely not useful and a simple static js file and static jQuery initialization statement is good enough. Not every jQuery component is worth converting to a WiQuery component. The ones that are worth are often:
> - components that are ajax enabled and/or;
> - components that have their jQuery options depend on data or logic and/or;
> - components that have their visibility or are enabled based on data or logic and/or;
> - components that are added by an ajax request and not at page load;
>
>
> The reason I started working on the WiQuery project is because my company creates enterprise administration applications where we have *a lot* of pages with ajax replaced panels, autocomplete text fields, accordion panels, tabbed panels, feedback popups... you name it we have it.
> With WiQuery we create reusable components, define which resources this component needs and what bit of jQuery it needs to initialize after the page (or ajax response) has been loaded, and simple add them to the page. The page is on a need to know basis, it will define the layout not boss all components around... WiQuery checks which resources are loaded, removes duplicates, adds the jQuery Core, jQuery UI and jQuery UI Theme. While managing multiple projects with over 1000+ pages, this takes away quite a load off our shoulders.
>
> Maarten says:
> Writing what should be JavaScript in your wicket Java code is quite out-of-place, and generally all you need to do is place your code where it belongs, in a .js or your markup.
>
> I wonder if he ever really used WiQuery or even looked how it's used. Or for that matter used jQuery. What you *don't* need to do with WiQuery is write js code in your java classes and we recommend to put all js code in js files and load them as a resource! To create a jQuery wicket component you:
> - write your jQuery js file and the html file that comes with it;
> - write the java code that you need to insert any application data, behaviors or validators;
> - let your component implement an interface (so WiQuery can detect it upon creation) to define which js/css files you want to be added as a resource and define the jQuery initialization statement with java code (which is translated most often something like "document.onready(.....);".
>
>
> There are other libraries around that do about the same as WiQuery, and perhaps better or faster, but my rant above is to clarify why the project exists and why people are using it. And the best part of it is: you don't have to use it...
>
> Regards,
>
> Hielke
>
> -----Original Message-----
> From: Bruno Borges [mailto:bruno.borges@gmail.com]
> Sent: donderdag 7 april 2011 0:32
> To: users@wicket.apache.org
> Cc: Maarten Billemont
> Subject: Re: Wiquery experiences
>
> Most of the things you want to do with jQuery, you don't need a library for.
>
> I totally agree with Maarten
>
>
> Bruno Borges
> www.brunoborges.com.br
> +55 21 76727099
>
> "The glory of great men should always be measured by the means they have used to acquire it."
> - Francois de La Rochefoucauld
>
>
>
> On Wed, Apr 6, 2011 at 6:15 AM, Maarten Billemont <lh...@gmail.com> wrote:
>
>> Unless WiQuery has matured a *lot* lately and the code has been
>> cleaned up significantly, I can't recommend it, personally.
>>
>> Writing what should be JavaScript in your wicket Java code is quite
>> out-of-place, and generally all you need to do is place your code
>> where it belongs, in a .js or your markup.
>>
>> There may be some odd cases here or there where tighter integration of
>> jQuery and Wicket can be beneficial, but those can usually be resolved
>> some other way.
>>
>> I don't have enough experience or knowledge of the framework to cast a
>> final vote though, all I'm saying is: beware of the quality of this
>> library's code and make sure you actually need it first (I want to do
>> jQuery stuff in my Wicket application is generally not reason enough).
>>
>> On 06 Apr 2011, at 11:09, haiko@dds.nl wrote:
>>
>> > Hi,
>> >
>> > We are thinking of using wiquery for a project. We are interested in
>> > the
>> experiences of people using it. Does wiquery work in the major
>> browsers (IE7, IE8, IE9, FF3 and Chrome)? Are there any complications
>> when different versions of jquery are used on other places in the
>> HTML? What is the version of Wicket you used it?
>> >
>> > Please share your experiences.
>> >
>> > Thanks in advance,
>> >
>> > Haiko van der Schaaf
>> >
>> >
>> > --------------------------------------------------------------------
>> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Wiquery experiences
Posted by Hielke Hoeve <Hi...@topicus.nl>.
WiQuery *has* matured a lot. We are working hard in our late hours to implement and test interfaces to all facets of jQuery and are getting ready for Wicket 1.5.
Bruno is right that for some purposes it is easy using only jQuery, simply add the jQuery js files you want and write a script tag with the document.onready function. But I am curious how one handles ajax added panels with jQuery functionality on a page or components that consume data or jquery enabled components that have jQuery options set based on business logic or components that have their visibility set based on business logic. Once a component is replaced by an ajax call the jQuery functionality is removed from this component. Not to speak of being able to reuse numerous components on numerous pages... I don't even want to begin to think about how to handle jquery component options based on business data.
Now I do agree that in some cases (which do not cover the ones I described above) WiQuery is absolutely not useful and a simple static js file and static jQuery initialization statement is good enough. Not every jQuery component is worth converting to a WiQuery component. The ones that are worth are often:
- components that are ajax enabled and/or;
- components that have their jQuery options depend on data or logic and/or;
- components that have their visibility or are enabled based on data or logic and/or;
- components that are added by an ajax request and not at page load;
The reason I started working on the WiQuery project is because my company creates enterprise administration applications where we have *a lot* of pages with ajax replaced panels, autocomplete text fields, accordion panels, tabbed panels, feedback popups... you name it we have it.
With WiQuery we create reusable components, define which resources this component needs and what bit of jQuery it needs to initialize after the page (or ajax response) has been loaded, and simple add them to the page. The page is on a need to know basis, it will define the layout not boss all components around... WiQuery checks which resources are loaded, removes duplicates, adds the jQuery Core, jQuery UI and jQuery UI Theme. While managing multiple projects with over 1000+ pages, this takes away quite a load off our shoulders.
Maarten says:
Writing what should be JavaScript in your wicket Java code is quite out-of-place, and generally all you need to do is place your code where it belongs, in a .js or your markup.
I wonder if he ever really used WiQuery or even looked how it's used. Or for that matter used jQuery. What you *don't* need to do with WiQuery is write js code in your java classes and we recommend to put all js code in js files and load them as a resource! To create a jQuery wicket component you:
- write your jQuery js file and the html file that comes with it;
- write the java code that you need to insert any application data, behaviors or validators;
- let your component implement an interface (so WiQuery can detect it upon creation) to define which js/css files you want to be added as a resource and define the jQuery initialization statement with java code (which is translated most often something like "document.onready(.....);".
There are other libraries around that do about the same as WiQuery, and perhaps better or faster, but my rant above is to clarify why the project exists and why people are using it. And the best part of it is: you don't have to use it...
Regards,
Hielke
-----Original Message-----
From: Bruno Borges [mailto:bruno.borges@gmail.com]
Sent: donderdag 7 april 2011 0:32
To: users@wicket.apache.org
Cc: Maarten Billemont
Subject: Re: Wiquery experiences
Most of the things you want to do with jQuery, you don't need a library for.
I totally agree with Maarten
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
"The glory of great men should always be measured by the means they have used to acquire it."
- Francois de La Rochefoucauld
On Wed, Apr 6, 2011 at 6:15 AM, Maarten Billemont <lh...@gmail.com> wrote:
> Unless WiQuery has matured a *lot* lately and the code has been
> cleaned up significantly, I can't recommend it, personally.
>
> Writing what should be JavaScript in your wicket Java code is quite
> out-of-place, and generally all you need to do is place your code
> where it belongs, in a .js or your markup.
>
> There may be some odd cases here or there where tighter integration of
> jQuery and Wicket can be beneficial, but those can usually be resolved
> some other way.
>
> I don't have enough experience or knowledge of the framework to cast a
> final vote though, all I'm saying is: beware of the quality of this
> library's code and make sure you actually need it first (I want to do
> jQuery stuff in my Wicket application is generally not reason enough).
>
> On 06 Apr 2011, at 11:09, haiko@dds.nl wrote:
>
> > Hi,
> >
> > We are thinking of using wiquery for a project. We are interested in
> > the
> experiences of people using it. Does wiquery work in the major
> browsers (IE7, IE8, IE9, FF3 and Chrome)? Are there any complications
> when different versions of jquery are used on other places in the
> HTML? What is the version of Wicket you used it?
> >
> > Please share your experiences.
> >
> > Thanks in advance,
> >
> > Haiko van der Schaaf
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
RE: Wiquery experiences
Posted by msj121 <ms...@gmail.com>.
Keep in mind I do use WiQuery myself primarily for the Resource Manager, my
main point was that this is the main reason to use WiQuery, like you
mentioned, and that it should only be viewed as an interface was in my
opinion more of a compliment to well written code. And of course people who
don't know jquery or javascript will gain a lot from WiQuery bypassing much
of that knowledge.
I do admit that there are regular updates to WiQuery, but there was some
time where it did not convert its source jquery files to the newer versions
of JQuery (which I understand requires testing etc... and cannot be done
quickly), which I think now can be overriden more easily by the user.
My other main fear is that with a couple of JQuery Wicket modules, which
will stay and be adopted and which will go. I personally hope that WiQuery
will continue to be updated and grow, but with only a couple of people as
maintainers, I thought it could become extinct all of a sudden at any time.
Though it is good to know that it is being used by an organization, which
means there is monetary incentive for them to keep it afloat.
But yes, I do think that WiQuery is a great project! Though I do need to one
day solve issue 77, I am hoping with the new versions of wicket/wiquery it
will have been somehow solved though I may have solved it by working around
the problem which is probably better code.
Hielke Hoeve-2 wrote:
>
>>
>>-----Original Message-----
>>From: msj121 [mailto:msj242@gmail.com]
>>Sent: donderdag 7 april 2011 2:13
>>To: users@wicket.apache.org
>>Subject: Re: Wiquery experiences
>>
>>I both agree and disagree with the aforementioned comments.
>>
>>I don't think anyone would disagree that writing JavaScript from wicket
> or using a decorator to write JavaScript is wrong. In fact quite often I
> may not know the id of an object until run-time and I may want the
> javascript to run on a specific textfield with no extra class names or
> additional tags marking it. To say that you need an extra .js file for a
> one-line or even 20 line simple js command is arguable I think.
>
> Hence we created the JsScope.quickScope(). However others, like Maarten,
> do not like this function as it allows people to write js code in a java
> class. There are more than 1 way to use WiQuery and everyone can use
> their favorite one.
>
>>That being said, if you know JavaScript or jQuery, probably WiQuery is
> not the most necessary, it is really an object oriented interface to
> jQuery, not much more as I recall.
>
> That and resource manager. That is all it needs to be, because otherwise
> it would be slow, large in jar size and unmaintainable.
>
>>The best advantage to WiQuery I find is that JQuery at page ready can
> run numerous sets of commands.... All you need to do with WiQuery is add
> these commands and they are all grouped together and run in a single
> document ready function. Similarly WiQuery will take care of keeping
> track of what object id to run the script against, JavaScript files to
> import etc.... It does simplify things, but do you NEED another library,
> some people want to keep as few dependencies as possible, some don't
> care.
>>Remember the real engine is JQuery, WiQuery is just an interface to
> simplify. But look at writing javascript plainly in Wicket. If it is
> easy for you, probably don't bother, but if your getting a headache you
> might want to use WiQuery.
>
> Hooray for freedom of choice! :-)
>
>>My main fear is how often it may be updated and how long will it be
> around.
>>I have WiQuery in a current project I may take it out, I notice I
> mostly have been writing my own jQuery anyway.
>
> Since January we have released 4 new 1.2 versions in which we fixed a
> great deal of bugs and added new features, like the YUI compressor to
> compress resources when in production mode. We have started to work on a
> wicket 1.5 version and are nearing RC status.
>
> Hielke
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wiquery-experiences-tp3430320p3433900.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Wiquery experiences
Posted by Hielke Hoeve <Hi...@topicus.nl>.
>
>-----Original Message-----
>From: msj121 [mailto:msj242@gmail.com]
>Sent: donderdag 7 april 2011 2:13
>To: users@wicket.apache.org
>Subject: Re: Wiquery experiences
>
>I both agree and disagree with the aforementioned comments.
>
>I don't think anyone would disagree that writing JavaScript from wicket
or using a decorator to write JavaScript is wrong. In fact quite often I
may not know the id of an object until run-time and I may want the
javascript to run on a specific textfield with no extra class names or
additional tags marking it. To say that you need an extra .js file for a
one-line or even 20 line simple js command is arguable I think.
Hence we created the JsScope.quickScope(). However others, like Maarten,
do not like this function as it allows people to write js code in a java
class. There are more than 1 way to use WiQuery and everyone can use
their favorite one.
>That being said, if you know JavaScript or jQuery, probably WiQuery is
not the most necessary, it is really an object oriented interface to
jQuery, not much more as I recall.
That and resource manager. That is all it needs to be, because otherwise
it would be slow, large in jar size and unmaintainable.
>The best advantage to WiQuery I find is that JQuery at page ready can
run numerous sets of commands.... All you need to do with WiQuery is add
these commands and they are all grouped together and run in a single
document ready function. Similarly WiQuery will take care of keeping
track of what object id to run the script against, JavaScript files to
import etc.... It does simplify things, but do you NEED another library,
some people want to keep as few dependencies as possible, some don't
care.
>Remember the real engine is JQuery, WiQuery is just an interface to
simplify. But look at writing javascript plainly in Wicket. If it is
easy for you, probably don't bother, but if your getting a headache you
might want to use WiQuery.
Hooray for freedom of choice! :-)
>My main fear is how often it may be updated and how long will it be
around.
>I have WiQuery in a current project I may take it out, I notice I
mostly have been writing my own jQuery anyway.
Since January we have released 4 new 1.2 versions in which we fixed a
great deal of bugs and added new features, like the YUI compressor to
compress resources when in production mode. We have started to work on a
wicket 1.5 version and are nearing RC status.
Hielke
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wiquery experiences
Posted by msj121 <ms...@gmail.com>.
I both agree and disagree with the aforementioned comments.
I don't think anyone would disagree that writing javascript from wicket or
using a decorator to write javascript is wrong. In fact quite often I may
not know the id of an object until run-time and I may want the javascript to
run on a specific textfield with no extra class names or additional tags
marking it. To say that you need an extra .js file for a one-line or even 20
line simple js command is arguable I think.
That being said, if you know javascript or jquery, probably WiQuery is not
the most necessary, it is really an object oriented interface to jquery, not
much more as I recall.
The best advantage to wiquery I find is that JQuery at page ready can run
numerous sets of commands.... All you need to do with WiQuery is add these
commands and they are all grouped together and run in a single document
ready function. Similarly WiQuery will take care of keeping track of what
object id to run the script against, javascript files to import etc.... It
does simplify things, but do you NEED another library, some people want to
keep as few dependencies as possible, some don't care.
Remember the real engine is JQuery, WiQuery is just an interface to
simplify. But look at writing javascript plainly in Wicket. If it is easy
for you, probably don't bother, but if your getting a headache you might
want to use WiQuery.
My main fear is how often it may be updated and how long will it be around.
I have WiQuery in a current project I may take it out, I notice I mostly
have been writing my own jquery anyway.
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wiquery-experiences-tp3430320p3432209.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wiquery experiences
Posted by Bruno Borges <br...@gmail.com>.
Most of the things you want to do with jQuery, you don't need a library for.
I totally agree with Maarten
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
"The glory of great men should always be
measured by the means they have used to
acquire it."
- Francois de La Rochefoucauld
On Wed, Apr 6, 2011 at 6:15 AM, Maarten Billemont <lh...@gmail.com> wrote:
> Unless WiQuery has matured a *lot* lately and the code has been cleaned up
> significantly, I can't recommend it, personally.
>
> Writing what should be JavaScript in your wicket Java code is quite
> out-of-place, and generally all you need to do is place your code where it
> belongs, in a .js or your markup.
>
> There may be some odd cases here or there where tighter integration of
> jQuery and Wicket can be beneficial, but those can usually be resolved some
> other way.
>
> I don't have enough experience or knowledge of the framework to cast a
> final vote though, all I'm saying is: beware of the quality of this
> library's code and make sure you actually need it first (I want to do jQuery
> stuff in my Wicket application is generally not reason enough).
>
> On 06 Apr 2011, at 11:09, haiko@dds.nl wrote:
>
> > Hi,
> >
> > We are thinking of using wiquery for a project. We are interested in the
> experiences of people using it. Does wiquery work in the major browsers
> (IE7, IE8, IE9, FF3 and Chrome)? Are there any complications when different
> versions of jquery are used on other places in the HTML? What is the version
> of Wicket you used it?
> >
> > Please share your experiences.
> >
> > Thanks in advance,
> >
> > Haiko van der Schaaf
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wiquery experiences
Posted by Maarten Billemont <lh...@gmail.com>.
Unless WiQuery has matured a *lot* lately and the code has been cleaned up significantly, I can't recommend it, personally.
Writing what should be JavaScript in your wicket Java code is quite out-of-place, and generally all you need to do is place your code where it belongs, in a .js or your markup.
There may be some odd cases here or there where tighter integration of jQuery and Wicket can be beneficial, but those can usually be resolved some other way.
I don't have enough experience or knowledge of the framework to cast a final vote though, all I'm saying is: beware of the quality of this library's code and make sure you actually need it first (I want to do jQuery stuff in my Wicket application is generally not reason enough).
On 06 Apr 2011, at 11:09, haiko@dds.nl wrote:
> Hi,
>
> We are thinking of using wiquery for a project. We are interested in the experiences of people using it. Does wiquery work in the major browsers (IE7, IE8, IE9, FF3 and Chrome)? Are there any complications when different versions of jquery are used on other places in the HTML? What is the version of Wicket you used it?
>
> Please share your experiences.
>
> Thanks in advance,
>
> Haiko van der Schaaf
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org