AW: jQuery form validation with wicket ajax

2012-02-15 Thread Gerrit Scholz | QUERPLEX.de
I prepend if(!$('.register').valid()) { return false;}; to the onclick 
attribute.
This statement call the jQuery validator for the form.

The onclick attribute without my changes (AjaxRequestTarget not null): 

onclick=var wcall=wicketSubmitFormById('contactForm8', 
'../kemner/?wicket:interface=:4:contactForm:sendContact::IActivePageBehaviorListener:0:1wicket:ignoreIfNotActive=true',
 'sendContact' ,function() { }.bind(this),function() { }.bind(this), function() 
{return Wicket.$$(this)Wicket.$$('contactForm8')}.bind(this));;; return 
false;

onclick with my changes (AjaxRequestTarget null):

onclick= if(!$('.register').valid()) { return false;}; var 
wcall=wicketSubmitFormById('contactForm8', 
'../kemner/?wicket:interface=:4:contactForm:sendContact::IActivePageBehaviorListener:0:1wicket:ignoreIfNotActive=true',
 'sendContact' ,function() { }.bind(this),function() { }.bind(this), function() 
{return Wicket.$$(this)Wicket.$$('contactForm8')}.bind(this));;; return 
false;

Gerrit

-Ursprüngliche Nachricht-
Von: Alec Swan [mailto:alecs...@gmail.com] 
Gesendet: Dienstag, 14. Februar 2012 18:50
An: users@wicket.apache.org
Betreff: Re: jQuery form validation with wicket ajax

Are you saying that AjaxRequestTarget is not null without your onclick 
attribute changes and is null with your changes? If so, please post the changes 
you made to onclick attribute.

On Tue, Feb 14, 2012 at 7:06 AM, Gerrit Scholz | QUERPLEX.de 
gerrit.sch...@querplex.de wrote:
 If I intercept the onclick event my function is called but the processing not 
 stop. Mean that the wicket (onclick) javascript is running parallel.
 So I write a AttributeModifier that prepends my function to the onclick 
 attribute. Now the validation works fine, but on the onSubmit method of the 
 wicket ajax button the AjaxRequestTarget is null so the component to refresh 
 cannot be added.

 Gerrit

 -Ursprüngliche Nachricht-
 Von: Paul Jackson [mailto:paul.jack...@cdl.co.uk]
 Gesendet: Dienstag, 14. Februar 2012 10:38
 An: users@wicket.apache.org
 Betreff: RE: jQuery form validation with wicket ajax

 Thanks for that link! I never managed to work out how to get jquery events to 
 override the buttons onClick attribute. This should simplify our validation 
 code a lot.

 Paul

 -Original Message-
 From: Alec Swan [mailto:alecs...@gmail.com]
 Sent: 13 February 2012 16:38
 To: users@wicket.apache.org
 Subject: Re: jQuery form validation with wicket ajax

 This thread describes a purely client-side solution to your problem:
 http://stackoverflow.com/questions/1506729/how-to-intercept-the-onclick-event.
 You can solve this problem for all you AJAX links by assigning them a special 
 class, e.g. class=ajaxLink, and then apply the technique to $(form 
 .ajaxLink).

 On Mon, Feb 13, 2012 at 3:55 AM, Paul Jackson paul.jack...@cdl.co.uk wrote:
 We use an OnBeforeRenderListener to add onClick events to the buttons and 
 ajax buttons on a form that we want to be validated. We have to handle the 
 normal buttons and ajax buttons slightly differently.

 Ajax button:

            button.add(new AttributeModifier(onclick, new 
 ModelString(if (! $('# + formMarkupId
                    + ').validate().form()) {return false};)) {

 Normal Button:

            button.add(new WiQueryEventBehavior(new
 Event(MouseEvent.CLICK) {
                @Override
                public JsScope callback() {
                    return JsScope.quickScope(return $('# + 
 formMarkupId + ').validate().form(););
                }
            }));

 Hope that helps.

 Paul

 -Original Message-
 From: Gerrit Scholz | QUERPLEX.de [mailto:gerrit.sch...@querplex.de]
 Sent: 13 February 2012 10:18
 To: users@wicket.apache.org
 Subject: jQuery form validation with wicket ajax

 Hello there,
 I try to use jQuery validaton (http://docs.jquery.com/Plugins/Validation) 
 with a wicket AJAX button. I register the jQuery validator on the form. If I 
 use a normal wicket submit button or link, the jQuery form validation works. 
 But if I use an AJAX button or link, the jQuery form validation is not 
 called. How can I call the jQuery validation before AJAX update.
 Thanks,
 Gerrit



 -
 -
 - QUERPLEX GmbH Nürnberg | www.querplex.de Kornmarkt 2
 D-90402 Nürnberg
 -
 -
 -
 Tel +49 (0)911 94 11 98 - 0
 Fax +49 (0)911 94 11 98 - 59
 -
 -
 -
 Registergericht Nürnberg HRB 20 123
 Geschäftsführerin: Angelika Benkert
 -
 -
 -
 *
 * Please consider the environment - do you really need to print this 
 email?

 This email is intended only for the person(s) named above and may contain 
 private and confidential information. If it has come 

RE: jQuery form validation with wicket ajax

2012-02-15 Thread Paul Jackson

This works for us:

onclick=if (! $('#id45').validate().form()) {return false};if 
(function(){return Wicket.$$(this)Wicket.$$('id45')}.bind(this)()) { 
Wicket.showIncrementally('busyIndicator');}var 
wcall=wicketSubmitFormById('id45', 
'?x=cu02w6454cTq5HSn4Av8ZXGRwfcS*bDlrHDXn8GklQ6Sh3RC2Dgwz8XwqsEQE*Jo7KvmsA5Uh0NowPRWPoKW7z8clW5Md9oNtKs9d1v0BgjqKNKS-oluEmHYF0Tjrkqq8T76MXi*zlTAtfj5YLHG3gKsV2tb4R*z',
 'address:pafForm:pafSearch' ,function() { 
;Wicket.hideIncrementally('busyIndicator');}.bind(this),function() { 
;Wicket.hideIncrementally('busyIndicator');}.bind(this), function() {return 
Wicket.$$(this)Wicket.$$('id45')}.bind(this));;; return false;

It's basically the same, with some extras bits for busy indicators and such.

Paul

-Original Message-
From: Gerrit Scholz | QUERPLEX.de [mailto:gerrit.sch...@querplex.de] 
Sent: 15 February 2012 09:09
To: users@wicket.apache.org
Subject: AW: jQuery form validation with wicket ajax

I prepend if(!$('.register').valid()) { return false;}; to the onclick 
attribute.
This statement call the jQuery validator for the form.

The onclick attribute without my changes (AjaxRequestTarget not null): 

onclick=var wcall=wicketSubmitFormById('contactForm8', 
'../kemner/?wicket:interface=:4:contactForm:sendContact::IActivePageBehaviorListener:0:1wicket:ignoreIfNotActive=true',
 'sendContact' ,function() { }.bind(this),function() { }.bind(this), function() 
{return Wicket.$$(this)Wicket.$$('contactForm8')}.bind(this));;; return 
false;

onclick with my changes (AjaxRequestTarget null):

onclick= if(!$('.register').valid()) { return false;}; var 
wcall=wicketSubmitFormById('contactForm8', 
'../kemner/?wicket:interface=:4:contactForm:sendContact::IActivePageBehaviorListener:0:1wicket:ignoreIfNotActive=true',
 'sendContact' ,function() { }.bind(this),function() { }.bind(this), function() 
{return Wicket.$$(this)Wicket.$$('contactForm8')}.bind(this));;; return 
false;

Gerrit

-Ursprüngliche Nachricht-
Von: Alec Swan [mailto:alecs...@gmail.com]
Gesendet: Dienstag, 14. Februar 2012 18:50
An: users@wicket.apache.org
Betreff: Re: jQuery form validation with wicket ajax

Are you saying that AjaxRequestTarget is not null without your onclick 
attribute changes and is null with your changes? If so, please post the changes 
you made to onclick attribute.

On Tue, Feb 14, 2012 at 7:06 AM, Gerrit Scholz | QUERPLEX.de 
gerrit.sch...@querplex.de wrote:
 If I intercept the onclick event my function is called but the processing not 
 stop. Mean that the wicket (onclick) javascript is running parallel.
 So I write a AttributeModifier that prepends my function to the onclick 
 attribute. Now the validation works fine, but on the onSubmit method of the 
 wicket ajax button the AjaxRequestTarget is null so the component to refresh 
 cannot be added.

 Gerrit

 -Ursprüngliche Nachricht-
 Von: Paul Jackson [mailto:paul.jack...@cdl.co.uk]
 Gesendet: Dienstag, 14. Februar 2012 10:38
 An: users@wicket.apache.org
 Betreff: RE: jQuery form validation with wicket ajax

 Thanks for that link! I never managed to work out how to get jquery events to 
 override the buttons onClick attribute. This should simplify our validation 
 code a lot.

 Paul

 -Original Message-
 From: Alec Swan [mailto:alecs...@gmail.com]
 Sent: 13 February 2012 16:38
 To: users@wicket.apache.org
 Subject: Re: jQuery form validation with wicket ajax

 This thread describes a purely client-side solution to your problem:
 http://stackoverflow.com/questions/1506729/how-to-intercept-the-onclick-event.
 You can solve this problem for all you AJAX links by assigning them a special 
 class, e.g. class=ajaxLink, and then apply the technique to $(form 
 .ajaxLink).

 On Mon, Feb 13, 2012 at 3:55 AM, Paul Jackson paul.jack...@cdl.co.uk wrote:
 We use an OnBeforeRenderListener to add onClick events to the buttons and 
 ajax buttons on a form that we want to be validated. We have to handle the 
 normal buttons and ajax buttons slightly differently.

 Ajax button:

            button.add(new AttributeModifier(onclick, new 
 ModelString(if (! $('# + formMarkupId
                    + ').validate().form()) {return false};)) {

 Normal Button:

            button.add(new WiQueryEventBehavior(new
 Event(MouseEvent.CLICK) {
                @Override
                public JsScope callback() {
                    return JsScope.quickScope(return $('# + 
 formMarkupId + ').validate().form(););
                }
            }));

 Hope that helps.

 Paul

 -Original Message-
 From: Gerrit Scholz | QUERPLEX.de [mailto:gerrit.sch...@querplex.de]
 Sent: 13 February 2012 10:18
 To: users@wicket.apache.org
 Subject: jQuery form validation with wicket ajax

 Hello there,
 I try to use jQuery validaton (http://docs.jquery.com/Plugins/Validation) 
 with a wicket AJAX button. I register the jQuery validator on the form. If I 
 use a normal wicket submit button or link, the jQuery form validation works. 
 But if I use an 

Re: Too Many Files Open

2012-02-15 Thread Martijn Dashorst
Increase the number of file handles allowed by your unix box. For many
systems this limit is set too low.

Martijn

On Mon, Feb 13, 2012 at 10:33 PM, Wooldridge, Keith A
keith.wooldri...@mantech.com wrote:
 We recently upgraded to Tomcat 7 and Wicket 1.5.3.  After the upgrade, we 
 started getting an error saying that too many files were open.  After looking 
 for information about this, I found a link going back to 1.4.1 where someone 
 else was having this problem:

 http://apache-wicket.1842946.n4.nabble.com/Too-Many-Files-Wicket-1-4-1-td1875839.html

 The error specifically points to 
 apache-tomcat-7.0.25/work/Catalina/localhost/app/wicketApplication-filestore. 
  Has anyone found a resolution for this problem?

 Thanks,

 Keith Wooldridge




-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Wicket jQuery Validator integration

2012-02-15 Thread Zachary Bedell
Good morning,

Reading a recent thread about accessing jQuery Validation from Wicket reminded 
me that I've developed some code that might be of use.  I'm not sure if this is 
something anyone else would be interested in or if it's something that might 
eventually be integrated into Wicket core or if it would be more appropriate 
for one of the existing jQuery/Wicket integration libraries.  I wanted to 
describe what I've cooked up so far.  If this is anything that would be useful, 
I'd be willing to clean the code up a bit to extract a few bits that are 
specific to our environment and post the code somewhere.

My intent was to get client-side validation using Wicket's existing validation 
classes without requiring AJAX calls to make them work and preferably without 
requiring Page's to include lots of unsightly JavaScript.  Also, not 
duplicating validation logic on the client  server tiers was desirable.  The 
code was originally developed for a site that was expected to receive a high 
amount of traffic in a short period of time, and avoiding unnecessary server 
calls was a priority.  

I created a subclass of Form (ClientSideValidatingForm) which examines each 
FormComponent (and sub-Form) added to it and extracts information about the 
standard Wicket validations.  It generates JavaScript which uses jQuery's 
Validator library to apply client-side checks equivalent to the Wicket server 
side checks.  The nice thing about this is that you get client-side validation 
for free just by adding the normal Wicket validations plus you still get all 
your validations backed up in the server side in case JavaScript is unavailable 
or disabled.

The implementation of the class does lack a bit in terms of elegance 
unfortunately.  As the Wicket validation interface doesn't currently know 
anything about JavaScript, it was necessary to run a chain of instanceof checks 
against all the known Wicket validations and emit JavaScript to mirror their 
logic.  I also created an extension of the Wicket IValidator interface which 
can provide JavaScript functions to perform validation equivalent to the 
server-side Java code.  The extraction code in ClientSideValidatingForm 
preferentially checks for this interface and uses provided JavaScript if 
available.  Otherwise, it's a bunch of instanceof's to check for known 
validations or log an error if an unknown instance of IValidator is found.

Long term, it would be helpful if the stock Wicket IValidator interface could 
include a method to get JavaScript validations for all of the stock validations.

The code is pretty tightly bound to jQuery Validator at this point, but it's 
likely the methodology could be abstracted to other validation frameworks.  
It's also built using WiQuery, though that's mostly as a convenience to get the 
same version of jQuery that we use elsewhere.  The same could easily be 
implemented without WiQuery provided a version of jQuery was contributed to the 
response via some other mechanism.

Is this something anyone would be interested in?  

Best regards,
Zac Bedell
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Wicket jQuery Validator integration

2012-02-15 Thread Zachary Bedell
Good morning,

Reading a recent thread about accessing jQuery Validation from Wicket reminded 
me that I've developed some code that might be of use.  I'm not sure if this is 
something anyone else would be interested in or if it's something that might 
eventually be integrated into Wicket core or if it would be more appropriate 
for one of the existing jQuery/Wicket integration libraries.  I wanted to 
describe what I've cooked up so far.  If this is anything that would be useful, 
I'd be willing to clean the code up a bit to extract a few bits that are 
specific to our environment and post the code somewhere.

My intent was to get client-side validation using Wicket's existing validation 
classes without requiring AJAX calls to make them work and preferably without 
requiring Page's to include lots of unsightly JavaScript.  Also, not 
duplicating validation logic on the client  server tiers was desirable.  The 
code was originally developed for a site that was expected to receive a high 
amount of traffic in a short period of time, and avoiding unnecessary server 
calls was a priority.  

I created a subclass of Form (ClientSideValidatingForm) which examines each 
FormComponent (and sub-Form) added to it and extracts information about the 
standard Wicket validations.  It generates JavaScript which uses jQuery's 
Validator library to apply client-side checks equivalent to the Wicket server 
side checks.  The nice thing about this is that you get client-side validation 
for free just by adding the normal Wicket validations plus you still get all 
your validations backed up in the server side in case JavaScript is unavailable 
or disabled.

The implementation of the class does lack a bit in terms of elegance 
unfortunately.  As the Wicket validation interface doesn't currently know 
anything about JavaScript, it was necessary to run a chain of instanceof checks 
against all the known Wicket validations and emit JavaScript to mirror their 
logic.  I also created an extension of the Wicket IValidator interface which 
can provide JavaScript functions to perform validation equivalent to the 
server-side Java code.  The extraction code in ClientSideValidatingForm 
preferentially checks for this interface and uses provided JavaScript if 
available.  Otherwise, it's a bunch of instanceof's to check for known 
validations or log an error if an unknown instance of IValidator is found.

Long term, it would be helpful if the stock Wicket IValidator interface could 
include a method to get JavaScript validations for all of the stock validations.

The code is pretty tightly bound to jQuery Validator at this point, but it's 
likely the methodology could be abstracted to other validation frameworks.  
It's also built using WiQuery, though that's mostly as a convenience to get the 
same version of jQuery that we use elsewhere.  The same could easily be 
implemented without WiQuery provided a version of jQuery was contributed to the 
response via some other mechanism.

Is this something anyone would be interested in?  

Best regards,
Zac Bedell

(Apologies if this is a dupe. I had some email client config issues this 
morning...)


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: jQuery form validation with wicket ajax

2012-02-15 Thread Alec Swan
Gerrit, You need to call .valid().form(), not just .valid(). Also, you
should probably use the form id #contactForm8 instead of '.register'
jQuery selector. In other words, use Paul's code snippet:
button.add(new AttributeModifier(onclick, new ModelString(if (!
$('# + formMarkupId + ').validate().form()) {return false};))

On Wed, Feb 15, 2012 at 2:18 AM, Paul Jackson paul.jack...@cdl.co.uk wrote:

 This works for us:

 onclick=if (! $('#id45').validate().form()) {return false};if 
 (function(){return Wicket.$$(this)Wicket.$$('id45')}.bind(this)()) { 
 Wicket.showIncrementally('busyIndicator');}var 
 wcall=wicketSubmitFormById('id45', 
 '?x=cu02w6454cTq5HSn4Av8ZXGRwfcS*bDlrHDXn8GklQ6Sh3RC2Dgwz8XwqsEQE*Jo7KvmsA5Uh0NowPRWPoKW7z8clW5Md9oNtKs9d1v0BgjqKNKS-oluEmHYF0Tjrkqq8T76MXi*zlTAtfj5YLHG3gKsV2tb4R*z',
  'address:pafForm:pafSearch' ,function() { 
 ;Wicket.hideIncrementally('busyIndicator');}.bind(this),function() { 
 ;Wicket.hideIncrementally('busyIndicator');}.bind(this), function() {return 
 Wicket.$$(this)Wicket.$$('id45')}.bind(this));;; return false;

 It's basically the same, with some extras bits for busy indicators and such.

 Paul

 -Original Message-
 From: Gerrit Scholz | QUERPLEX.de [mailto:gerrit.sch...@querplex.de]
 Sent: 15 February 2012 09:09
 To: users@wicket.apache.org
 Subject: AW: jQuery form validation with wicket ajax

 I prepend if(!$('.register').valid()) { return false;}; to the onclick 
 attribute.
 This statement call the jQuery validator for the form.

 The onclick attribute without my changes (AjaxRequestTarget not null):

 onclick=var wcall=wicketSubmitFormById('contactForm8', 
 '../kemner/?wicket:interface=:4:contactForm:sendContact::IActivePageBehaviorListener:0:1wicket:ignoreIfNotActive=true',
  'sendContact' ,function() { }.bind(this),function() { }.bind(this), 
 function() {return Wicket.$$(this)Wicket.$$('contactForm8')}.bind(this));;; 
 return false;

 onclick with my changes (AjaxRequestTarget null):

 onclick= if(!$('.register').valid()) { return false;}; var 
 wcall=wicketSubmitFormById('contactForm8', 
 '../kemner/?wicket:interface=:4:contactForm:sendContact::IActivePageBehaviorListener:0:1wicket:ignoreIfNotActive=true',
  'sendContact' ,function() { }.bind(this),function() { }.bind(this), 
 function() {return Wicket.$$(this)Wicket.$$('contactForm8')}.bind(this));;; 
 return false;

 Gerrit

 -Ursprüngliche Nachricht-
 Von: Alec Swan [mailto:alecs...@gmail.com]
 Gesendet: Dienstag, 14. Februar 2012 18:50
 An: users@wicket.apache.org
 Betreff: Re: jQuery form validation with wicket ajax

 Are you saying that AjaxRequestTarget is not null without your onclick 
 attribute changes and is null with your changes? If so, please post the 
 changes you made to onclick attribute.

 On Tue, Feb 14, 2012 at 7:06 AM, Gerrit Scholz | QUERPLEX.de 
 gerrit.sch...@querplex.de wrote:
 If I intercept the onclick event my function is called but the processing 
 not stop. Mean that the wicket (onclick) javascript is running parallel.
 So I write a AttributeModifier that prepends my function to the onclick 
 attribute. Now the validation works fine, but on the onSubmit method of the 
 wicket ajax button the AjaxRequestTarget is null so the component to refresh 
 cannot be added.

 Gerrit

 -Ursprüngliche Nachricht-
 Von: Paul Jackson [mailto:paul.jack...@cdl.co.uk]
 Gesendet: Dienstag, 14. Februar 2012 10:38
 An: users@wicket.apache.org
 Betreff: RE: jQuery form validation with wicket ajax

 Thanks for that link! I never managed to work out how to get jquery events 
 to override the buttons onClick attribute. This should simplify our 
 validation code a lot.

 Paul

 -Original Message-
 From: Alec Swan [mailto:alecs...@gmail.com]
 Sent: 13 February 2012 16:38
 To: users@wicket.apache.org
 Subject: Re: jQuery form validation with wicket ajax

 This thread describes a purely client-side solution to your problem:
 http://stackoverflow.com/questions/1506729/how-to-intercept-the-onclick-event.
 You can solve this problem for all you AJAX links by assigning them a 
 special class, e.g. class=ajaxLink, and then apply the technique to 
 $(form .ajaxLink).

 On Mon, Feb 13, 2012 at 3:55 AM, Paul Jackson paul.jack...@cdl.co.uk wrote:
 We use an OnBeforeRenderListener to add onClick events to the buttons and 
 ajax buttons on a form that we want to be validated. We have to handle the 
 normal buttons and ajax buttons slightly differently.

 Ajax button:

            button.add(new AttributeModifier(onclick, new
 ModelString(if (! $('# + formMarkupId
                    + ').validate().form()) {return false};)) {

 Normal Button:

            button.add(new WiQueryEventBehavior(new
 Event(MouseEvent.CLICK) {
                @Override
                public JsScope callback() {
                    return JsScope.quickScope(return $('# +
 formMarkupId + ').validate().form(););
                }
            }));

 Hope that helps.

 Paul

 -Original Message-
 

RE: Wicket jQuery Validator integration

2012-02-15 Thread Paul Jackson
We do something very similar to this, and agree that it works really
well. We also use JSR303 annotations on our domain models and use them
to drive adding both wicket and jquery validators. 

We have a bunch of ValdiationConfiguration classes that know what to add
to the markup and javascript to get the client side validation to work,
so we don't need an extension to IValidator.

Cheers,
Paul

-Original Message-
From: Zachary Bedell [mailto:zacl...@thebedells.org] 
Sent: 15 February 2012 15:52
To: users@wicket.apache.org
Subject: Wicket jQuery Validator integration

Good morning,

Reading a recent thread about accessing jQuery Validation from Wicket
reminded me that I've developed some code that might be of use.  I'm not
sure if this is something anyone else would be interested in or if it's
something that might eventually be integrated into Wicket core or if it
would be more appropriate for one of the existing jQuery/Wicket
integration libraries.  I wanted to describe what I've cooked up so far.
If this is anything that would be useful, I'd be willing to clean the
code up a bit to extract a few bits that are specific to our environment
and post the code somewhere.

My intent was to get client-side validation using Wicket's existing
validation classes without requiring AJAX calls to make them work and
preferably without requiring Page's to include lots of unsightly
JavaScript.  Also, not duplicating validation logic on the client 
server tiers was desirable.  The code was originally developed for a
site that was expected to receive a high amount of traffic in a short
period of time, and avoiding unnecessary server calls was a priority.  

I created a subclass of Form (ClientSideValidatingForm) which examines
each FormComponent (and sub-Form) added to it and extracts information
about the standard Wicket validations.  It generates JavaScript which
uses jQuery's Validator library to apply client-side checks equivalent
to the Wicket server side checks.  The nice thing about this is that you
get client-side validation for free just by adding the normal Wicket
validations plus you still get all your validations backed up in the
server side in case JavaScript is unavailable or disabled.

The implementation of the class does lack a bit in terms of elegance
unfortunately.  As the Wicket validation interface doesn't currently
know anything about JavaScript, it was necessary to run a chain of
instanceof checks against all the known Wicket validations and emit
JavaScript to mirror their logic.  I also created an extension of the
Wicket IValidator interface which can provide JavaScript functions to
perform validation equivalent to the server-side Java code.  The
extraction code in ClientSideValidatingForm preferentially checks for
this interface and uses provided JavaScript if available.  Otherwise,
it's a bunch of instanceof's to check for known validations or log an
error if an unknown instance of IValidator is found.

Long term, it would be helpful if the stock Wicket IValidator interface
could include a method to get JavaScript validations for all of the
stock validations.

The code is pretty tightly bound to jQuery Validator at this point, but
it's likely the methodology could be abstracted to other validation
frameworks.  It's also built using WiQuery, though that's mostly as a
convenience to get the same version of jQuery that we use elsewhere.
The same could easily be implemented without WiQuery provided a version
of jQuery was contributed to the response via some other mechanism.

Is this something anyone would be interested in?  

Best regards,
Zac Bedell

(Apologies if this is a dupe. I had some email client config issues this
morning...)


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

**
Please consider the environment - do you really need to print this email?

This email is intended only for the person(s) named above and may contain 
private and confidential information. If it has come to you in error, please 
destroy and permanently delete any copy in your possession and contact us on 
+44 (0) 161 480 4420. The information in this email is copyright © CDL Group 
Holdings Limited. We cannot accept any liability for any loss or damage 
sustained as a result of software viruses. It is your responsibility to carry 
out such virus checking as is necessary before opening any attachment.

Cheshire Datasystems Limited uses software which automatically screens incoming 
emails for inappropriate content and attachments. If the software identifies 
such content or attachment, the email will be forwarded to our Technology 
Department for checking. You should be aware that any email which you send to 
Cheshire Datasystems Limited is subject to this procedure.

Cheshire Datasystems Limited, Strata 

AbstractPageableView cachedItemCount

2012-02-15 Thread Jonathan Tougas
I noticed two count queries go by when using the DataTable component. so I
searched and dug up this jira issue
https://issues.apache.org/jira/browse/WICKET-1766 which is a won't fix.

Igor states that two queries are required each request, but I see this
differently:

The count is a used as the basis for the paging navigator's isVisible(), so
far so good. The issue is that the count is discarded in onDetach() (as
well as readObject()). It's state and as such should not be discarded when
the request is finished, it's still needed for things like checking if a
link was indeed visible when a click comes in for it. If it's not kept, a
new query to the model will be made, which might return a different result
- consequences ensue. The critical part of that is we are checking if the
link *was* visible, not if it *is* visible.

I think the only time it should be discarded is in the onBeforeRender()
event. This is when we are actually interested in going back to the model
to see if the value has changed. So to me this is indeed a bug. I don't
mind patching something up myself, or reopening the ticket...but I would
like a confirmation that I'm not way out in left field ;)

Cheers!
Jonathan Tougas


Re: AbstractPageableView cachedItemCount

2012-02-15 Thread Dan Retzlaff
Hi, Jonathan. Which component are you referring to? I don't see isVisible()
overrides in PagingNavigator or its helpers.


 It's state and as such should not be discarded when
 the request is finished, it's still needed for things like checking if a
 link was indeed visible when a click comes in for it.


How can you receive a click event for a link that was not visible?
Invisible components aren't rendered.

That JIRA discusses multiple size() calls in a single request. You're
discussing multiple size() calls with multiple requests. Right?

Dan

On Wed, Feb 15, 2012 at 9:31 AM, Jonathan Tougas jtou...@gmail.com wrote:

 I noticed two count queries go by when using the DataTable component. so I
 searched and dug up this jira issue
 https://issues.apache.org/jira/browse/WICKET-1766 which is a won't fix.

 Igor states that two queries are required each request, but I see this
 differently:

 The count is a used as the basis for the paging navigator's isVisible(), so
 far so good. The issue is that the count is discarded in onDetach() (as
 well as readObject()). It's state and as such should not be discarded when
 the request is finished, it's still needed for things like checking if a
 link was indeed visible when a click comes in for it. If it's not kept, a
 new query to the model will be made, which might return a different result
 - consequences ensue. The critical part of that is we are checking if the
 link *was* visible, not if it *is* visible.

 I think the only time it should be discarded is in the onBeforeRender()
 event. This is when we are actually interested in going back to the model
 to see if the value has changed. So to me this is indeed a bug. I don't
 mind patching something up myself, or reopening the ticket...but I would
 like a confirmation that I'm not way out in left field ;)

 Cheers!
 Jonathan Tougas



PageParameters in 1.5.3 vs 1.5.4

2012-02-15 Thread Lawrence, Sean
Hi,

I'm noticing a difference in the way search parameters are handled in 1.5.4 vs 
1.5.3 after upgrading wicket. Basically, identical parameters are eliminated. 
See example below

Passing the identical list of search parameters to our SearchResultsPage:

URL with 1.5.3:

https://localhost/app/wicket/bookmarkable/pages.SearchResultsPage?41paramsqt1=QUERYmf1=dDocTitlepr=%3Csubstring%3Eop1=%3COR%3Eqt1=QUERYmf1=namepr=%3Csubstring%3Eop1=%3COR%3Eqt1=QUERYmf1=nameCOpr=%3Csubstring%3Eop1=%3COR%3Eqt1=QUERYmf1=nameCSpr=%3Csubstring%3Eop1=%3COR%3Eqt1=QUERYmf1=dddpr=%3Csubstring%3Eop1=%3COR%3Eqt1=QUERYmf1=abNumberpr=%3Csubstring%3Eop1=%3COR%3EsortField=dCreateDatesortOrder=descsortField=dDocTitlesortOrder=ascas=falseqs=true

URL with 1.5.4:

https://localhost/app/wicket/bookmarkable/pages.SearchResultsPage?30paramsqt1=QUERYmf1=dDocTitlemf1=namemf1=nameCOmf1=nameCSmf1=dddmf1=abNumberpr=%3Csubstring%3Eop1=%3COR%3EsortField=dCreateDatesortField=dDocTitlesortOrder=descsortOrder=ascas=falseqs=true

Noticed how the identical op1=OR, pr=substring, and qt=QUERY params were 
all reduced to one entry in 1.5.4.

Because we are dependent on 1.5.3's behavior for our searches the 1.5.4 
behavior is breaking things, as well as eliminating the ability to keep rows 
synced across columns when parameters might be related.

Questions:

(1) Will the way 1.5.4 is handling identical search parameters be the desired 
behavior going forward with Wicket and

(2) if this is the desired behavior is there a better way to handle our 
searches that involve syncing across columns/arrays like this (with variable 
rows) ?

Thanks,

Sean Lawrence




Re: AbstractPageableView cachedItemCount

2012-02-15 Thread Jonathan Tougas
The PagingNavigationIncrementLink's linksTo(Page), which calls isLast()
which calls pageable getPageCount() which ends up calling size()
eventually. This is called during Component.canCallListenerInterface (*you're
right it's not isVisible*) to verify if the link can indeed be clicked.

And to be clear I am discussing multiple size() calls in one request. It
happens when clicking on the navigation links: size() is called first as
part of the verifying if the link is enabled (as described above), then the
cached value is discarded just before rendering (in onBeforeRender()). Then
size() is called again as part of the rendering, and again cached. The
cached value is again discarded at the end of the request in onDetach().
What I'm saying is the the first size() shouldn't occur because the page
count should be cached from the previous rendering (it shouldn't be cleared
in onDetach() nor readObject()).

On Wed, Feb 15, 2012 at 1:09 PM, Dan Retzlaff dretzl...@gmail.com wrote:

 Hi, Jonathan. Which component are you referring to? I don't see isVisible()
 overrides in PagingNavigator or its helpers.


  It's state and as such should not be discarded when
  the request is finished, it's still needed for things like checking if a
  link was indeed visible when a click comes in for it.


 How can you receive a click event for a link that was not visible?
 Invisible components aren't rendered.

 That JIRA discusses multiple size() calls in a single request. You're
 discussing multiple size() calls with multiple requests. Right?

 Dan

 On Wed, Feb 15, 2012 at 9:31 AM, Jonathan Tougas jtou...@gmail.com
 wrote:

  I noticed two count queries go by when using the DataTable component. so
 I
  searched and dug up this jira issue
  https://issues.apache.org/jira/browse/WICKET-1766 which is a won't
 fix.
 
  Igor states that two queries are required each request, but I see this
  differently:
 
  The count is a used as the basis for the paging navigator's isVisible(),
 so
  far so good. The issue is that the count is discarded in onDetach() (as
  well as readObject()). It's state and as such should not be discarded
 when
  the request is finished, it's still needed for things like checking if a
  link was indeed visible when a click comes in for it. If it's not kept, a
  new query to the model will be made, which might return a different
 result
  - consequences ensue. The critical part of that is we are checking if the
  link *was* visible, not if it *is* visible.
 
  I think the only time it should be discarded is in the onBeforeRender()
  event. This is when we are actually interested in going back to the model
  to see if the value has changed. So to me this is indeed a bug. I don't
  mind patching something up myself, or reopening the ticket...but I would
  like a confirmation that I'm not way out in left field ;)
 
  Cheers!
  Jonathan Tougas
 



Re: AbstractPageableView cachedItemCount

2012-02-15 Thread Dan Retzlaff
Thanks for the clarification. I see your point now: if records are deleted
from the database, the navigation click is ignored an the page is simply
re-rendered. But if the data content has changed such that the navigation
no longer makes sense, what behavior would you prefer?

On Wed, Feb 15, 2012 at 1:37 PM, Jonathan Tougas jtou...@gmail.com wrote:

 The PagingNavigationIncrementLink's linksTo(Page), which calls isLast()
 which calls pageable getPageCount() which ends up calling size()
 eventually. This is called during Component.canCallListenerInterface
 (*you're
 right it's not isVisible*) to verify if the link can indeed be clicked.

 And to be clear I am discussing multiple size() calls in one request. It
 happens when clicking on the navigation links: size() is called first as
 part of the verifying if the link is enabled (as described above), then the
 cached value is discarded just before rendering (in onBeforeRender()). Then
 size() is called again as part of the rendering, and again cached. The
 cached value is again discarded at the end of the request in onDetach().
 What I'm saying is the the first size() shouldn't occur because the page
 count should be cached from the previous rendering (it shouldn't be cleared
 in onDetach() nor readObject()).

 On Wed, Feb 15, 2012 at 1:09 PM, Dan Retzlaff dretzl...@gmail.com wrote:

  Hi, Jonathan. Which component are you referring to? I don't see
 isVisible()
  overrides in PagingNavigator or its helpers.
 
 
   It's state and as such should not be discarded when
   the request is finished, it's still needed for things like checking if
 a
   link was indeed visible when a click comes in for it.
 
 
  How can you receive a click event for a link that was not visible?
  Invisible components aren't rendered.
 
  That JIRA discusses multiple size() calls in a single request. You're
  discussing multiple size() calls with multiple requests. Right?
 
  Dan
 
  On Wed, Feb 15, 2012 at 9:31 AM, Jonathan Tougas jtou...@gmail.com
  wrote:
 
   I noticed two count queries go by when using the DataTable component.
 so
  I
   searched and dug up this jira issue
   https://issues.apache.org/jira/browse/WICKET-1766 which is a won't
  fix.
  
   Igor states that two queries are required each request, but I see this
   differently:
  
   The count is a used as the basis for the paging navigator's
 isVisible(),
  so
   far so good. The issue is that the count is discarded in onDetach() (as
   well as readObject()). It's state and as such should not be discarded
  when
   the request is finished, it's still needed for things like checking if
 a
   link was indeed visible when a click comes in for it. If it's not
 kept, a
   new query to the model will be made, which might return a different
  result
   - consequences ensue. The critical part of that is we are checking if
 the
   link *was* visible, not if it *is* visible.
  
   I think the only time it should be discarded is in the onBeforeRender()
   event. This is when we are actually interested in going back to the
 model
   to see if the value has changed. So to me this is indeed a bug. I don't
   mind patching something up myself, or reopening the ticket...but I
 would
   like a confirmation that I'm not way out in left field ;)
  
   Cheers!
   Jonathan Tougas
  
 



RE: continueToOriginalDestination seems to be incorrectly retaining destination across multiple logins

2012-02-15 Thread Evan Sable
Thanks for your response Martin, and sorry for my delayed reply!

I added the breakpoint (it's line 210 in my 1.5-SNAPSHOT).  I also put one at 
line 197, at the start of the mapRequest method, to see if it was getting into 
the method and finding a null value for the data variable.  But neither 
breakpoint gets reached so the method is not being called.  Does this mean that 
something is wrong with my wicket/shiro integration code, regarding the wicket 
request processing not being used correctly?  I should add that I'm using a 
library from this fifyfive-wicket project (see 
https://github.com/55minutes/fiftyfive-wicket#readme) that pretty much sets up 
the wicket/shiro integration for me.  Does it sound like the problem is most 
likely coming from there, or might something else be going on?  

Thanks again,
-Evan

-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org] 
Sent: Thursday, February 09, 2012 3:12 AM
To: users@wicket.apache.org
Subject: Re: continueToOriginalDestination seems to be incorrectly retaining 
destination across multiple logins

Hi,

The intercept data should be cleaned at
org.apache.wicket.RestartResponseAtInterceptPageException, line 211 - 
InterceptData.clear(); Put a breakpoint there and see what happens.

On Wed, Feb 8, 2012 at 7:55 PM, Evan Sable e...@novelution.com wrote:
 Hi,



 I'm using wicket 1.5-SNAPSHOT along with Shiro for 
 authentication/authorization security, and when an unauthorized user 
 tries to go to a page, Shiro calls redirectToInterceptPage behind the 
 scenes, and during the login process, after a successful login, there is code 
 that says:

 if (!continueToOriginalDestination()) {

   setResponsePage(getApplication().getHomePage());

 }



 It is working in the sense that if a user gets redirected to login, 
 they are taken to the correct destination afterwards, and if a user 
 just clicks the login link in a new browser they are redirected to the 
 homepage after login.



 BUT, the problem is, if an initial user tries to go to a protected 
 page, gets redirected to the login, logs in, and then logs out, and 
 then, without closing the browser, clicks the login link and logs in 
 with the same user again or even another user, it still redirects to the 
 prior original
 destination, which should no longer take effect.  I would think that 
 this should be forgotten upon logging out, which replaces the wicket 
 session
 with:

 Session session = Session.get();

 session.replaceSession();



 I think I must be misunderstanding how continueToOriginalDestination 
 is working - I thought it was placing the original destination url 
 into the users session, which is why I figured that after the login 
 which redirects, followed by the logout which replaces the session, it would 
 be gone.



 Can someone please explain what I'm thinking about wrongly here and 
 why the destination is being retained across multiple logins.  Also, 
 how can I avoid this so that the original destination is only used the 
 first time?Btw, just to be clear, if I logout and then click to a 
 new protected url, the original destination value is properly 
 replaced with the new protected destination which redirects back to 
 the intercept page.  The problem is only if I click directly to the 
 login page without a new intercept, but after having previously 
 utilized the continueToOriginalDestination in the prior login.

 Thanks very much for any help!

 -Evan




--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Feedback Panel exposes password in cleartext if minimumLength test fails

2012-02-15 Thread pblakez
Gidday

when I add password field with minimumLength and the user enters an shorter
password it is displayed in the feedback panel in cleartext
is there a work around for this ?

e.g.
form.add(new
PasswordTextField(pass).add(StringValidator.minimumLength(8)).setLabel(new
ModelString(Password:)));

feedback = '123456' is shorter than the minimum of 8 characters.


Wicket 1.5.3


cheers pb...

*follow  ==*   https://www.twitter.com/@pblakez
https://www.facebook.com/pblakez


Re: Feedback Panel exposes password in cleartext if minimumLength test fails

2012-02-15 Thread Igor Vaynberg
override the validator message to not show the value...

-igor

On Wed, Feb 15, 2012 at 3:11 PM, pblakez pbla...@gmail.com wrote:
 Gidday

 when I add password field with minimumLength and the user enters an shorter
 password it is displayed in the feedback panel in cleartext
 is there a work around for this ?

 e.g.
 form.add(new
 PasswordTextField(pass).add(StringValidator.minimumLength(8)).setLabel(new
 ModelString(Password:)));

 feedback = '123456' is shorter than the minimum of 8 characters.


 Wicket 1.5.3


 cheers pb...

 *follow  ==*   https://www.twitter.com/@pblakez
 https://www.facebook.com/pblakez

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: AbstractPageableView cachedItemCount

2012-02-15 Thread Jonathan Tougas
The cachedItemCount calculated in onBeforeRender should not be discarded at
the end of a request (so the clear in onDetach and readObject shouldn't be
there). This way it would still be around when a request comes in to handle
a click.

On Wed, Feb 15, 2012 at 5:19 PM, Dan Retzlaff dretzl...@gmail.com wrote:

 Thanks for the clarification. I see your point now: if records are deleted
 from the database, the navigation click is ignored an the page is simply
 re-rendered. But if the data content has changed such that the navigation
 no longer makes sense, what behavior would you prefer?

 On Wed, Feb 15, 2012 at 1:37 PM, Jonathan Tougas jtou...@gmail.com
 wrote:

  The PagingNavigationIncrementLink's linksTo(Page), which calls isLast()
  which calls pageable getPageCount() which ends up calling size()
  eventually. This is called during Component.canCallListenerInterface
  (*you're
  right it's not isVisible*) to verify if the link can indeed be clicked.
 
  And to be clear I am discussing multiple size() calls in one request. It
  happens when clicking on the navigation links: size() is called first as
  part of the verifying if the link is enabled (as described above), then
 the
  cached value is discarded just before rendering (in onBeforeRender()).
 Then
  size() is called again as part of the rendering, and again cached. The
  cached value is again discarded at the end of the request in onDetach().
  What I'm saying is the the first size() shouldn't occur because the page
  count should be cached from the previous rendering (it shouldn't be
 cleared
  in onDetach() nor readObject()).
 
  On Wed, Feb 15, 2012 at 1:09 PM, Dan Retzlaff dretzl...@gmail.com
 wrote:
 
   Hi, Jonathan. Which component are you referring to? I don't see
  isVisible()
   overrides in PagingNavigator or its helpers.
  
  
It's state and as such should not be discarded when
the request is finished, it's still needed for things like checking
 if
  a
link was indeed visible when a click comes in for it.
  
  
   How can you receive a click event for a link that was not visible?
   Invisible components aren't rendered.
  
   That JIRA discusses multiple size() calls in a single request. You're
   discussing multiple size() calls with multiple requests. Right?
  
   Dan
  
   On Wed, Feb 15, 2012 at 9:31 AM, Jonathan Tougas jtou...@gmail.com
   wrote:
  
I noticed two count queries go by when using the DataTable component.
  so
   I
searched and dug up this jira issue
https://issues.apache.org/jira/browse/WICKET-1766 which is a won't
   fix.
   
Igor states that two queries are required each request, but I see
 this
differently:
   
The count is a used as the basis for the paging navigator's
  isVisible(),
   so
far so good. The issue is that the count is discarded in onDetach()
 (as
well as readObject()). It's state and as such should not be discarded
   when
the request is finished, it's still needed for things like checking
 if
  a
link was indeed visible when a click comes in for it. If it's not
  kept, a
new query to the model will be made, which might return a different
   result
- consequences ensue. The critical part of that is we are checking if
  the
link *was* visible, not if it *is* visible.
   
I think the only time it should be discarded is in the
 onBeforeRender()
event. This is when we are actually interested in going back to the
  model
to see if the value has changed. So to me this is indeed a bug. I
 don't
mind patching something up myself, or reopening the ticket...but I
  would
like a confirmation that I'm not way out in left field ;)
   
Cheers!
Jonathan Tougas
   
  
 



Re: AbstractPageableView cachedItemCount

2012-02-15 Thread Dan Retzlaff
I understand your suggestion. But if the page to which the link refers no
longer exists based on the new data content, isn't it a bad idea to go
there?

I feel like I'm drawing this out. Sorry for that. :)

On Wed, Feb 15, 2012 at 4:25 PM, Jonathan Tougas jtou...@gmail.com wrote:

 The cachedItemCount calculated in onBeforeRender should not be discarded at
 the end of a request (so the clear in onDetach and readObject shouldn't be
 there). This way it would still be around when a request comes in to handle
 a click.

 On Wed, Feb 15, 2012 at 5:19 PM, Dan Retzlaff dretzl...@gmail.com wrote:

  Thanks for the clarification. I see your point now: if records are
 deleted
  from the database, the navigation click is ignored an the page is simply
  re-rendered. But if the data content has changed such that the navigation
  no longer makes sense, what behavior would you prefer?
 
  On Wed, Feb 15, 2012 at 1:37 PM, Jonathan Tougas jtou...@gmail.com
  wrote:
 
   The PagingNavigationIncrementLink's linksTo(Page), which calls isLast()
   which calls pageable getPageCount() which ends up calling size()
   eventually. This is called during Component.canCallListenerInterface
   (*you're
   right it's not isVisible*) to verify if the link can indeed be clicked.
  
   And to be clear I am discussing multiple size() calls in one request.
 It
   happens when clicking on the navigation links: size() is called first
 as
   part of the verifying if the link is enabled (as described above), then
  the
   cached value is discarded just before rendering (in onBeforeRender()).
  Then
   size() is called again as part of the rendering, and again cached. The
   cached value is again discarded at the end of the request in
 onDetach().
   What I'm saying is the the first size() shouldn't occur because the
 page
   count should be cached from the previous rendering (it shouldn't be
  cleared
   in onDetach() nor readObject()).
  
   On Wed, Feb 15, 2012 at 1:09 PM, Dan Retzlaff dretzl...@gmail.com
  wrote:
  
Hi, Jonathan. Which component are you referring to? I don't see
   isVisible()
overrides in PagingNavigator or its helpers.
   
   
 It's state and as such should not be discarded when
 the request is finished, it's still needed for things like checking
  if
   a
 link was indeed visible when a click comes in for it.
   
   
How can you receive a click event for a link that was not visible?
Invisible components aren't rendered.
   
That JIRA discusses multiple size() calls in a single request. You're
discussing multiple size() calls with multiple requests. Right?
   
Dan
   
On Wed, Feb 15, 2012 at 9:31 AM, Jonathan Tougas jtou...@gmail.com
wrote:
   
 I noticed two count queries go by when using the DataTable
 component.
   so
I
 searched and dug up this jira issue
 https://issues.apache.org/jira/browse/WICKET-1766 which is a
 won't
fix.

 Igor states that two queries are required each request, but I see
  this
 differently:

 The count is a used as the basis for the paging navigator's
   isVisible(),
so
 far so good. The issue is that the count is discarded in onDetach()
  (as
 well as readObject()). It's state and as such should not be
 discarded
when
 the request is finished, it's still needed for things like checking
  if
   a
 link was indeed visible when a click comes in for it. If it's not
   kept, a
 new query to the model will be made, which might return a different
result
 - consequences ensue. The critical part of that is we are checking
 if
   the
 link *was* visible, not if it *is* visible.

 I think the only time it should be discarded is in the
  onBeforeRender()
 event. This is when we are actually interested in going back to the
   model
 to see if the value has changed. So to me this is indeed a bug. I
  don't
 mind patching something up myself, or reopening the ticket...but I
   would
 like a confirmation that I'm not way out in left field ;)

 Cheers!
 Jonathan Tougas

   
  
 



Re: AbstractPageableView cachedItemCount

2012-02-15 Thread Igor Vaynberg
so when should it be discarded?

-igor

On Wed, Feb 15, 2012 at 4:25 PM, Jonathan Tougas jtou...@gmail.com wrote:
 The cachedItemCount calculated in onBeforeRender should not be discarded at
 the end of a request (so the clear in onDetach and readObject shouldn't be
 there). This way it would still be around when a request comes in to handle
 a click.

 On Wed, Feb 15, 2012 at 5:19 PM, Dan Retzlaff dretzl...@gmail.com wrote:

 Thanks for the clarification. I see your point now: if records are deleted
 from the database, the navigation click is ignored an the page is simply
 re-rendered. But if the data content has changed such that the navigation
 no longer makes sense, what behavior would you prefer?

 On Wed, Feb 15, 2012 at 1:37 PM, Jonathan Tougas jtou...@gmail.com
 wrote:

  The PagingNavigationIncrementLink's linksTo(Page), which calls isLast()
  which calls pageable getPageCount() which ends up calling size()
  eventually. This is called during Component.canCallListenerInterface
  (*you're
  right it's not isVisible*) to verify if the link can indeed be clicked.
 
  And to be clear I am discussing multiple size() calls in one request. It
  happens when clicking on the navigation links: size() is called first as
  part of the verifying if the link is enabled (as described above), then
 the
  cached value is discarded just before rendering (in onBeforeRender()).
 Then
  size() is called again as part of the rendering, and again cached. The
  cached value is again discarded at the end of the request in onDetach().
  What I'm saying is the the first size() shouldn't occur because the page
  count should be cached from the previous rendering (it shouldn't be
 cleared
  in onDetach() nor readObject()).
 
  On Wed, Feb 15, 2012 at 1:09 PM, Dan Retzlaff dretzl...@gmail.com
 wrote:
 
   Hi, Jonathan. Which component are you referring to? I don't see
  isVisible()
   overrides in PagingNavigator or its helpers.
  
  
It's state and as such should not be discarded when
the request is finished, it's still needed for things like checking
 if
  a
link was indeed visible when a click comes in for it.
  
  
   How can you receive a click event for a link that was not visible?
   Invisible components aren't rendered.
  
   That JIRA discusses multiple size() calls in a single request. You're
   discussing multiple size() calls with multiple requests. Right?
  
   Dan
  
   On Wed, Feb 15, 2012 at 9:31 AM, Jonathan Tougas jtou...@gmail.com
   wrote:
  
I noticed two count queries go by when using the DataTable component.
  so
   I
searched and dug up this jira issue
https://issues.apache.org/jira/browse/WICKET-1766 which is a won't
   fix.
   
Igor states that two queries are required each request, but I see
 this
differently:
   
The count is a used as the basis for the paging navigator's
  isVisible(),
   so
far so good. The issue is that the count is discarded in onDetach()
 (as
well as readObject()). It's state and as such should not be discarded
   when
the request is finished, it's still needed for things like checking
 if
  a
link was indeed visible when a click comes in for it. If it's not
  kept, a
new query to the model will be made, which might return a different
   result
- consequences ensue. The critical part of that is we are checking if
  the
link *was* visible, not if it *is* visible.
   
I think the only time it should be discarded is in the
 onBeforeRender()
event. This is when we are actually interested in going back to the
  model
to see if the value has changed. So to me this is indeed a bug. I
 don't
mind patching something up myself, or reopening the ticket...but I
  would
like a confirmation that I'm not way out in left field ;)
   
Cheers!
Jonathan Tougas
   
  
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Feedback Panel exposes password in cleartext if minimumLength test fails

2012-02-15 Thread pblakez
ok that works thanks  igor


cheers pb...

On Thu, Feb 16, 2012 at 10:22 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 override the validator message to not show the value...

 -igor

 On Wed, Feb 15, 2012 at 3:11 PM, pblakez pbla...@gmail.com wrote:
  Gidday
 
  when I add password field with minimumLength and the user enters an
 shorter
  password it is displayed in the feedback panel in cleartext
  is there a work around for this ?
 
  e.g.
  form.add(new
 
 PasswordTextField(pass).add(StringValidator.minimumLength(8)).setLabel(new
  ModelString(Password:)));
 
  feedback = '123456' is shorter than the minimum of 8 characters.
 
 
  Wicket 1.5.3
 
 
  cheers pb...
 
  *follow  ==*   https://www.twitter.com/@pblakez
  https://www.facebook.com/pblakez

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-- 
cheers pb...

*follow  ==*   https://www.twitter.com/@pblakez
https://www.facebook.com/pblakez


New bie question . Custom Form Submit

2012-02-15 Thread atomix
I have a link which is outside of a Form ...
And I want that when user click the link, the Form is submited();

I did :

...
onClick(){
form.process(); // But the model of Form Components haven't updated
}
...

So what I should do for that easy request?




--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/New-bie-question-Custom-Form-Submit-tp4392995p4392995.html
Sent from the Users forum 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: New bie question . Custom Form Submit

2012-02-15 Thread vineet semwal
use submitlink

On Thu, Feb 16, 2012 at 10:28 AM, atomix say_i_love_you_4e...@yahoo.com wrote:
 I have a link which is outside of a Form ...
 And I want that when user click the link, the Form is submited();

 I did :

 ...
 onClick(){
 form.process(); // But the model of Form Components haven't updated
 }
 ...

 So what I should do for that easy request?




 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/New-bie-question-Custom-Form-Submit-tp4392995p4392995.html
 Sent from the Users forum 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




-- 
thank you,

regards,
Vineet Semwal

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New bie question . Custom Form Submit

2012-02-15 Thread atomix
The link is *OUT *of the Form

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/New-bie-question-Custom-Form-Submit-tp4392995p4393062.html
Sent from the Users forum 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: New bie question . Custom Form Submit

2012-02-15 Thread Sven Meier

Read javadoc of SubmitLink(String, Form)

Am 16.02.2012 06:46, schrieb atomix:

The link is *OUT *of the Form

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/New-bie-question-Custom-Form-Submit-tp4392995p4393062.html
Sent from the Users forum 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: New bie question . Custom Form Submit

2012-02-15 Thread vineet semwal
i *read* that , pass the form you want submitlink to submit in constructor

On Thu, Feb 16, 2012 at 11:16 AM, atomix say_i_love_you_4e...@yahoo.com wrote:
 The link is *OUT *of the Form

 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/New-bie-question-Custom-Form-Submit-tp4392995p4393062.html
 Sent from the Users forum 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




-- 
thank you,

regards,
Vineet Semwal

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New bie question . Custom Form Submit

2012-02-15 Thread Sven Meier

Sure, but I assume atomix hasn't ;)

Sven

Am 16.02.2012 07:10, schrieb vineet semwal:

i *read* that , pass the form you want submitlink to submit in constructor

On Thu, Feb 16, 2012 at 11:16 AM, atomixsay_i_love_you_4e...@yahoo.com  wrote:

The link is *OUT *of the Form

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/New-bie-question-Custom-Form-Submit-tp4392995p4393062.html
Sent from the Users forum 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: New bie question . Custom Form Submit

2012-02-15 Thread vineet semwal
hi sven,
sorry that reply was to atomix ,i saw your mail few seconds late else
i wouldnt have replied :)

On Thu, Feb 16, 2012 at 12:14 PM, Sven Meier s...@meiers.net wrote:
 Sure, but I assume atomix hasn't ;)

 Sven

 Am 16.02.2012 07:10, schrieb vineet semwal:

 i *read* that , pass the form you want submitlink to submit in constructor

 On Thu, Feb 16, 2012 at 11:16 AM, atomixsay_i_love_you_4e...@yahoo.com
  wrote:

 The link is *OUT *of the Form

 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/New-bie-question-Custom-Form-Submit-tp4392995p4393062.html
 Sent from the Users forum 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




-- 
thank you,

regards,
Vineet Semwal

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New bie question . Custom Form Submit

2012-02-15 Thread atomix
Ahh Thanks again... I didn't khow that the SubmitLink can be outside of a
Form ...
...but IMO , why can't another thing call a Form to be submit ...
like calling process() = what does this method really doing, why don't it
update all the models??

Thank for answer my silly questions. Wish you a good day!

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/New-bie-question-Custom-Form-Submit-tp4392995p4393213.html
Sent from the Users forum 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