Can I make a request that the ctors for
RequiredValidator, IntegerValidator and
LengthValidator be changed from private to protected
to support this?
Maybe EmailAddressPatternValidator should go the other
way and be changed from public to protected and be
made singleton to be consistent, even thou
Phil Kulak wrote:
On 7/21/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Sure, use a construction like:
TextField c = new TextField("field");
c.add(new TypeValidator(Date.class)
{
protected String resourceKey(FormComponent formComponent)
On 7/21/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> Sure, use a construction like:
>
> TextField c = new TextField("field");
> c.add(new TypeValidator(Date.class)
> {
> protected String resourceKey(FormComponent formComponent)
>
uot;${label} contains too many characters".
Igor
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Phil Kulak
> Sent: Thursday, July 21, 2005 9:40 AM
> To: wicket-user@lists.sourceforge.net
> Subject: Re: [Wicket-user] VOT
How about having FormComponent supply the resource key? It seems like
the means to uniqely identify a component (the resource key) belongs
in the component itself, not the validator.
On 7/21/05, Brad Pardee <[EMAIL PROTECTED]> wrote:
> It seems to me you have 2 user needs here:
>
> 1) Those appli
[EMAIL PROTECTED] On Behalf Of
Phil Kulak
Sent: Thursday, July 21, 2005 8:00 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
Yea, but if you don't create the validator yourself, you're
totally out of luck. What's wrong with
TED] On Behalf Of
> > Phil Kulak
> > Sent: Thursday, July 21, 2005 8:00 AM
> > To: wicket-user@lists.sourceforge.net
> > Subject: Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
> >
> > Yea, but if you don't create the validator yourself, you'
It seems to me you have 2 user needs here:
1) Those applications that follow a pretty standard
architecture where creating a Form properties file
similar to the forminput example suits their needs.
For these apps, sharing a static instance of a
validator is fine and results in less object
creatio
[EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Phil Kulak
> Sent: Thursday, July 21, 2005 8:00 AM
> To: wicket-user@lists.sourceforge.net
> Subject: Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
>
> Yea, but if you don't create the validat
Agreed there is a delicate balance. However, RequiredValidator allready
was a singleton, but as it was not thread safe, it shouldn't have been.
Furthermore, the comment in AbstractValidator also falsely noted that it
was threadsafe.
I am obviously not against statefull objects, but I think in
Yea, but if you don't create the validator yourself, you're totally
out of luck. What's wrong with validators holding state? They're just
going to attached to stateful components anyway. I mean, why stop
there? Let's make TextField thread safe too. :)
On 7/21/05, Eelco Hillenius <[EMAIL PROTECTED]
Chris Turner wrote:
I'm also +1 on making the current validators stateless.
Ok, thanks. Jonathan also was +1 btw.
However, I think we also need to keep supporting the ability to create
stateful validators.
Sure, I think that would be no problem. It is a user's responsibility
now though.
developers can do anything the want i think?
Just override the AbstractValidator and in that calls developers can
introduce state if they want..
Just the defaults (like required) shouldn't be statefull.
johan
Chris Turner wrote:
I'm also +1 on making the current validators stateless. However,
I'm also +1 on making the current validators stateless. However, I think
we also need to keep supporting the ability to create stateful
validators. A particular use case for this is that that validation rules
may be different for each user, for example:
I want to build a password validator. Ho
I think the Singleton approach for the validators is a correct design.
Validators would otherwise be created a lot of times (for each field a
multiple), so this will keep our memory usage and GC time down.
As such we must make sure we don't introduce any kind of state into the
validators. Espe
yes this looks fine to me.
then they can take it from the given component or give something else.
Eelco Hillenius wrote:
I guess resourceKey isn't such a good idea after all, as it breaks the
thread safety we just introduced. It should be enough to remove this
but make getResourceKey(FormCompo
I guess resourceKey isn't such a good idea after all, as it breaks the
thread safety we just introduced. It should be enough to remove this but
make getResourceKey(FormComponent) overridable, so people can do this
with annonymous classes. Slightly inconvient, but safe. And safe should
win over
Yes, but it is optional. So, if people don't use the resourceKey, the
validators hold no state. If they do, it holds state, which /could/ lead
to non-thread safe behaviour. My guess was that that would be clear
enough? Maybe we should get rid of the singleton required validator just
to be sure.
is the resourcekey for such a validator always the same?
Because now you have extracted out the formcomponent but introduced the
resourcekey.as a variable
Eelco Hillenius wrote:
How does this look (see attachement)?
Eelco
--
One thing though. I'm strongly thinking about making
protected String getResourceKey(FormComponent formComponent)
final. This means you can't provide it algoritmicly, but you can call one of
the error methods with the key you want, or you can even implement IValidator
directly.
The reason why
How does this look (see attachement)?
Eelco
/*
* $Id: AbstractValidator.java,v 1.27 2005/04/03 16:29:53 jonathanlocke Exp $
* $Revision: 1.27 $ $Date: 2005/04/03 16:29:53 $
*
* ==
* Licensed under the Apache License
Phil Kulak wrote:
I'm +1 only because while we break validation for this, I may be able
to push through my setResourceKey(String) change.
You allready did; implemented this two days ago :)
If it's not
currently thread-safe, why are all the validators singletons?
afaik, that's only Req
I'm +1 only because while we break validation for this, I may be able
to push through my setResourceKey(String) change. If it's not
currently thread-safe, why are all the validators singletons?
On 7/20/05, Erik van Oosten <[EMAIL PROTECTED]> wrote:
> +1
>
> Wicket should not depend too much on th
+1 Ditto
Igor
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Erik van Oosten
> Sent: Wednesday, July 20, 2005 7:47 AM
> To: wicket-user@lists.sourceforge.net
> Subject: RE: [Wicket-user] VOTE: make AbstractValidat
+1
Wicket should not depend too much on the cleverness of the average
programmer, especially when we talk about making code thread safe. I
have seen this being underestimated too often already.
Regards,
Erik.
---
SF.Net email is sponsore
Who is for this? It would mean breaking a lot of clients (dangerous
break too, as it means changing overridable methods), and imho it would
make the validators look a bit more ugly (every method has to be
extended with a FormComponent argument).
__
It maybe
+0 too.
It seems to be a little bit better by design, making it threadsafe. But
the real benefits are not clear no me. The gained speed improvement is
IMHO unmeasurable.
-Matej
Eelco Hillenius wrote:
Last week there was a discussion about making AbstractValidator thread
safe.
Who is for th
27 matches
Mail list logo
