Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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 though his would break some code. --- Eelco Hillenius <[EMAIL PROTECTED]> wrote: > Chris Turner wrote: > > 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. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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)
{
return "my.special.key";
}
});
Regards,
Eelco
Ah yes, but I'm just creating a delegate method, I don't create the
validators. They are passed to me by the person building the panel.
Now, if Java let my subclass instances, that would be sweet. I'd
prefer to not go the bytecode manipulation route, however. :)
In that case it is either the responsibility of your user (you could
help him/ her by provide factory methods for creating common validators)
or you have to use the decorator pattern. If you use the latter, and let
the user provide the key that should be used, you'll be flexible /and/
have your goal met.
Eelco
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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)
> {
> return "my.special.key";
> }
> });
>
> Regards,
>
> Eelco
Ah yes, but I'm just creating a delegate method, I don't create the
validators. They are passed to me by the person building the panel.
Now, if Java let my subclass instances, that would be sweet. I'd
prefer to not go the bytecode manipulation route, however. :)
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
RE: [Wicket-user] VOTE: make AbstractValidator threadsafe
The problem with this approach is that you are limited to a single error
message per component.
I think what we need is a label in the form component, or a resource key to
that label. The combination of this label and a resource key pointing to a
generic error message in the validator should allow us to create good error
messages.
For example if you have a text field with the label "First Name" and
max-string-length validator fails you can construct a message "First Name
contains too many characters" by using the combination of component label
and validator message "${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] VOTE: make AbstractValidator threadsafe
>
> 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 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 creation/garbage collection.
> >
> > 2) Those applications that for whatever reason can't or
> don't want to
> > use a resourceKey generated based on the FormComponent and instead
> > want to specify their own resourceKey. For these users, it
> would be
> > easiest if they were able to set the resourceKey in the
> validator, but
> > otherwise they can get around this by extending the
> validator classes
> > or creating anonymous inner classes (provided singleton
> classes like
> > RequiredValidator change their default ctor to protected).
> >
> > Well, my application falls under #2, so you know what side I'll be
> > arguing. I think most of the validators already have
> state, be it the
> > range values for IntegerValidator or whatever. It might be argued
> > that a single static instance with this range would be
> created, but I
> > would also create a single static instance that also includes my
> > resource key. I think that in practice, the only real
> object creation
> > savings occurs when using the RequiredValidator. I think in the
> > future the plan is to allow the use of ${label}, so at that point
> > wouldn't it make sense to create a single static validator with a
> > specified resource key with value of "field '${label}' is
> required."
> > How would you achieve this without the resource key, unless
> you allow
> > wildcards in the properties file like:
> > "*.*.RequiredValidator=field '${label}' is required"
> >
> > I can see both sides, but I personally don't like the idea
> of having
> > to extend each Validator for my case.
> > I know this is a less than ideal solution, but how about if
> a ctor was
> > added that included the resourceKey and the setter was
> removed. Would
> > that make it explicit that you use the one default ctor for
> stateless
> > and the resourceKey ctor for stateful?
> >
> > Anyway, just my rambling stream of consciousness.
> > I've been using wicket for less than 2 weeks, to I may be
> completely
> > off base or missing something obvious (I think its awesome, btw).
> >
> > -Brad
> >
> >
> >
> > --- Eelco Hillenius <[EMAIL PROTECTED]>
> > wrote:
> >
> > > 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.
> >
> >
> >
> > ---
> > SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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 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
> creation/garbage collection.
>
> 2) Those applications that for whatever reason can't
> or don't want to use a resourceKey generated based on
> the FormComponent and instead want to specify their
> own resourceKey. For these users, it would be easiest
> if they were able to set the resourceKey in the
> validator, but otherwise they can get around this by
> extending the validator classes or creating anonymous
> inner classes (provided singleton classes like
> RequiredValidator change their default ctor to
> protected).
>
> Well, my application falls under #2, so you know what
> side I'll be arguing. I think most of the validators
> already have state, be it the range values for
> IntegerValidator or whatever. It might be argued that
> a single static instance with this range would be
> created, but I would also create a single static
> instance that also includes my resource key. I think
> that in practice, the only real object creation
> savings occurs when using the RequiredValidator. I
> think in the future the plan is to allow the use of
> ${label}, so at that point wouldn't it make sense to
> create a single static validator with a specified
> resource key with value of "field '${label}' is
> required." How would you achieve this without the
> resource key, unless you allow wildcards in the
> properties file like:
> "*.*.RequiredValidator=field '${label}' is required"
>
> I can see both sides, but I personally don't like the
> idea of having to extend each Validator for my case.
> I know this is a less than ideal solution, but how
> about if a ctor was added that included the
> resourceKey and the setter was removed. Would that
> make it explicit that you use the one default ctor for
> stateless and the resourceKey ctor for stateful?
>
> Anyway, just my rambling stream of consciousness.
> I've been using wicket for less than 2 weeks, to I may
> be completely off base or missing something obvious (I
> think its awesome, btw).
>
> -Brad
>
>
>
> --- Eelco Hillenius <[EMAIL PROTECTED]>
> wrote:
>
> > 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.
>
>
>
> ---
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> ___
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
Sure, use a construction like:
TextField c = new TextField("field");
c.add(new TypeValidator(Date.class)
{
protected String resourceKey(FormComponent formComponent)
{
return "my.special.key";
}
});
Regards,
Eelco
Phil Kulak wrote:
Alright, then could someone take a look at my problem with GridPanel?
Here's the issue: I need to create a panel for each type of form input
so that it can toggle between the form component and a label. Because
of this, I need to create a delegate for add(IValidator) on the panel
that adds the validator to the form component. All the validators need
a non-default resource key, since the default creats duplicates in a
ListView. Any ideas?
On 7/21/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
Use cases for validators are different, that's why it makes sense in one but
not the other. Text fields ultimately live inside a user's session so they
are threadsafe by default, validators on the other hand can be shared as
singletons.
Igor
-Original Message-
From: [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 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]> 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(FormComponent) overridable, so
people can do
this with annonymous classes. Slightly inconvient, but
safe. And safe
should win over inconvient.
Eelco
---
SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies from IBM. Find simple to follow Roadmaps,
straightforward articles, informative Webcasts and more! Get
everything you need to get up to speed, fast.
http://ads.osdn.com/?ad_idt77&alloc_id492&op=ick
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&opclick
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
Alright, then could someone take a look at my problem with GridPanel? Here's the issue: I need to create a panel for each type of form input so that it can toggle between the form component and a label. Because of this, I need to create a delegate for add(IValidator) on the panel that adds the validator to the form component. All the validators need a non-default resource key, since the default creats duplicates in a ListView. Any ideas? On 7/21/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > Use cases for validators are different, that's why it makes sense in one but > not the other. Text fields ultimately live inside a user's session so they > are threadsafe by default, validators on the other hand can be shared as > singletons. > > Igor > > > -Original Message- > > From: [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 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]> 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(FormComponent) overridable, so > > people can do > > > this with annonymous classes. Slightly inconvient, but > > safe. And safe > > > should win over inconvient. > > > > > > Eelco > > > > > > > > > --- > > SF.Net email is sponsored by: Discover Easy Linux Migration > > Strategies from IBM. Find simple to follow Roadmaps, > > straightforward articles, informative Webcasts and more! Get > > everything you need to get up to speed, fast. > > http://ads.osdn.com/?ad_idt77&alloc_id492&op=ick > > ___ > > Wicket-user mailing list > > Wicket-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > > > > > > > --- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&opclick > ___ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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
creation/garbage collection.
2) Those applications that for whatever reason can't
or don't want to use a resourceKey generated based on
the FormComponent and instead want to specify their
own resourceKey. For these users, it would be easiest
if they were able to set the resourceKey in the
validator, but otherwise they can get around this by
extending the validator classes or creating anonymous
inner classes (provided singleton classes like
RequiredValidator change their default ctor to
protected).
Well, my application falls under #2, so you know what
side I'll be arguing. I think most of the validators
already have state, be it the range values for
IntegerValidator or whatever. It might be argued that
a single static instance with this range would be
created, but I would also create a single static
instance that also includes my resource key. I think
that in practice, the only real object creation
savings occurs when using the RequiredValidator. I
think in the future the plan is to allow the use of
${label}, so at that point wouldn't it make sense to
create a single static validator with a specified
resource key with value of "field '${label}' is
required." How would you achieve this without the
resource key, unless you allow wildcards in the
properties file like:
"*.*.RequiredValidator=field '${label}' is required"
I can see both sides, but I personally don't like the
idea of having to extend each Validator for my case.
I know this is a less than ideal solution, but how
about if a ctor was added that included the
resourceKey and the setter was removed. Would that
make it explicit that you use the one default ctor for
stateless and the resourceKey ctor for stateful?
Anyway, just my rambling stream of consciousness.
I've been using wicket for less than 2 weeks, to I may
be completely off base or missing something obvious (I
think its awesome, btw).
-Brad
--- Eelco Hillenius <[EMAIL PROTECTED]>
wrote:
> 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.
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
RE: [Wicket-user] VOTE: make AbstractValidator threadsafe
Use cases for validators are different, that's why it makes sense in one but not the other. Text fields ultimately live inside a user's session so they are threadsafe by default, validators on the other hand can be shared as singletons. Igor > -Original Message- > From: [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 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]> 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(FormComponent) overridable, so > people can do > > this with annonymous classes. Slightly inconvient, but > safe. And safe > > should win over inconvient. > > > > Eelco > > > > > --- > SF.Net email is sponsored by: Discover Easy Linux Migration > Strategies from IBM. Find simple to follow Roadmaps, > straightforward articles, informative Webcasts and more! Get > everything you need to get up to speed, fast. > http://ads.osdn.com/?ad_idt77&alloc_id492&op=ick > ___ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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 this case it is good not to impose this on users (which we did). If you want to use state in your custom validators, you can do that without problems. If you want to your custom message key in validators, you can just subclass it. If you do this with an anonymous class, it is imo just slightly less elegant than setting the key on the object. If you create your custom validator for reuse in your own projects, you never have to think about it again. Though I am defending this now, please note that other people /did/ have problems with validators not being threadsafe. It's hard to have everybody happy. Eelco Phil Kulak wrote: 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]> 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(FormComponent) overridable, so people can do this with annonymous classes. Slightly inconvient, but safe. And safe should win over inconvient. Eelco --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
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 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]> 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(FormComponent) overridable, so people can do this > with annonymous classes. Slightly inconvient, but safe. And safe should > win over inconvient. > > Eelco > --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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. I think we have enough votes. I've committed the change. Regards, Eelco 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. However, the rules as to what makes a valid password are different dependent on what back-end systems a user can access (e.g. high security passwords for critical systems, lower security for customer documentation access). I therefore need to, at the time the password change form is created, determine what password rules I wish to apply (may involve expensive database access) and then create a validator instance for that form containing the rules that I determined. Obviously I could encode all these rules into my business logic and models, but I would rather do it at the web layer for efficiency and consistent error feedback purposes. regards, Chris Martijn Dashorst wrote: 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. Especially when the first goal was to make them threadsafe by removing state, we shouldn't introduce state again. -1 on the introduction of the stateful resourcekey. +1 on the stateless validators. Martijn Johan Compagner wrote: 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(FormComponent) overridable, so people can do this with annonymous classes. Slightly inconvient, but safe. And safe should win over inconvient. Eelco Eelco Hillenius wrote: 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... cheap enough to create such objects anyway. Eelco Johan Compagner wrote: 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 --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! G
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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 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. However, the rules as to what makes a valid password are different dependent on what back-end systems a user can access (e.g. high security passwords for critical systems, lower security for customer documentation access). I therefore need to, at the time the password change form is created, determine what password rules I wish to apply (may involve expensive database access) and then create a validator instance for that form containing the rules that I determined. Obviously I could encode all these rules into my business logic and models, but I would rather do it at the web layer for efficiency and consistent error feedback purposes. regards, Chris Martijn Dashorst wrote: 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. Especially when the first goal was to make them threadsafe by removing state, we shouldn't introduce state again. -1 on the introduction of the stateful resourcekey. +1 on the stateless validators. Martijn Johan Compagner wrote: 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(FormComponent) overridable, so people can do this with annonymous classes. Slightly inconvient, but safe. And safe should win over inconvient. Eelco Eelco Hillenius wrote: 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... cheap enough to create such objects anyway. Eelco Johan Compagner wrote: 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 --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and m
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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. However, the rules as to what makes a valid password are different dependent on what back-end systems a user can access (e.g. high security passwords for critical systems, lower security for customer documentation access). I therefore need to, at the time the password change form is created, determine what password rules I wish to apply (may involve expensive database access) and then create a validator instance for that form containing the rules that I determined. Obviously I could encode all these rules into my business logic and models, but I would rather do it at the web layer for efficiency and consistent error feedback purposes. regards, Chris Martijn Dashorst wrote: 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. Especially when the first goal was to make them threadsafe by removing state, we shouldn't introduce state again. -1 on the introduction of the stateful resourcekey. +1 on the stateless validators. Martijn Johan Compagner wrote: 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(FormComponent) overridable, so people can do this with annonymous classes. Slightly inconvient, but safe. And safe should win over inconvient. Eelco Eelco Hillenius wrote: 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... cheap enough to create such objects anyway. Eelco Johan Compagner wrote: 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 --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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. Especially when the first goal was to make them threadsafe by removing state, we shouldn't introduce state again. -1 on the introduction of the stateful resourcekey. +1 on the stateless validators. Martijn Johan Compagner wrote: 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(FormComponent) overridable, so people can do this with annonymous classes. Slightly inconvient, but safe. And safe should win over inconvient. Eelco Eelco Hillenius wrote: 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... cheap enough to create such objects anyway. Eelco Johan Compagner wrote: 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 --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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(FormComponent) overridable, so people can do this with annonymous classes. Slightly inconvient, but safe. And safe should win over inconvient. Eelco Eelco Hillenius wrote: 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... cheap enough to create such objects anyway. Eelco Johan Compagner wrote: 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 --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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 inconvient. Eelco Eelco Hillenius wrote: 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... cheap enough to create such objects anyway. Eelco Johan Compagner wrote: 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 --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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... cheap enough to create such objects anyway.
Eelco
Johan Compagner wrote:
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
/*
* $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, Version 2.0 (the "License");
you may not
* use this file except in compliance with the License. You may
obtain a copy of
* the License at
* * http://www.apache.org/licenses/LICENSE-2.0
* * Unless required by applicable law or agreed to in writing,
software
* distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the
* License for the specific language governing permissions and
limitations under
* the License.
*/
package wicket.markup.html.form.validation;
import java.util.HashMap;
import java.util.Map;
import wicket.Localizer;
import wicket.markup.html.form.FormComponent;
import wicket.model.IModel;
import wicket.model.Model;
import wicket.util.lang.Classes;
/**
* Base class for form component validators. This class is
thread-safe and therefore it is
* safe to share validators across sessions/threads.
*
* Error messages can be registered on a component by calling one of
the error(FormComponent ...)
* overloads. The error message will be retrieved using the Localizer
for the form
* component. Normally, this localizer will find the error message in
a string resource
* bundle (properties file) associated with the page in which this
validator is contained.
* The key that is used to get the message can be set explicity by
calling setResourceKey.
* If that key is not explicitly set, it default to the pattern:
* [form-name].[component-name].[validator-class].
* For example:
*
* MyForm.name.RequiredValidator=A name is required.
*
* Error message string resources can contain optional ognl variable
interpolations from
* the component, such as:
*
* editBook.name.LengthValidator='${input}' is too short a name.
*
* Available variables for interpolation are:
*
* ${input} - The user's input
* ${name} - The name of the component
*
* but specific validator subclasses may add more values.
*
* @author Jonathan Locke
* @author Eelco Hillenius
*/
public abstract class AbstractValidator implements IValidator
{
/**
* Any set resource key. When it is not set, the validator uses
it's default
* message key.
*/
private String resourceKey;
/**
* Sets an error on the component being validated using the map
returned by
* messageModel() for variable interpolations.
*
* See class comments for details about how error messages are
loaded and formatted.
* @param formComponent form component
*/
public void error(FormComponent formComponent)
{
error(formComponent, messageModel(formComponent));
}
/**
* Returns a formatted validation error message for a given
component. The error
* message is retrieved from a message bundle associated with the
page in which this
* validator is contained using the given resource key. The
resourceModel is used for
* variable interpolation.
* @param formComponent form component
* @param resourceKey The resource key to use
* @param resourceModel The model for variable interpolation
*/
public void error(FormComponent formComponent, final String
resourceKey,
final IModel resourceModel)
{
// Return formatted error message
Localizer localizer = formComponent.getLocalizer();
String message = localizer.getString(resourceKey,
formComponent, resourceModel);
formComponent.error(message);
}
/**
* Sets an error on the component being validated using the given
map for variable
* interpolations.
* @param formComponent form component
* @param resourceKey The resource key to use
* @param map The model for variable interpolation
*/
public void error(FormComponent formComponent, final String
resourceKey, final Map map)
{
error(formComponent, resourceKey, Model.valueOf(map));
}
/**
* Sets an error on the component being validated using the given
map for variable
* interpolations.
* @
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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
/*
* $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, Version 2.0 (the "License"); you may not
* use this file except in compliance with the License. You may obtain a copy of
* the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations under
* the License.
*/
package wicket.markup.html.form.validation;
import java.util.HashMap;
import java.util.Map;
import wicket.Localizer;
import wicket.markup.html.form.FormComponent;
import wicket.model.IModel;
import wicket.model.Model;
import wicket.util.lang.Classes;
/**
* Base class for form component validators. This class is thread-safe and
therefore it is
* safe to share validators across sessions/threads.
*
* Error messages can be registered on a component by calling one of the
error(FormComponent ...)
* overloads. The error message will be retrieved using the Localizer for the
form
* component. Normally, this localizer will find the error message in a string
resource
* bundle (properties file) associated with the page in which this validator is
contained.
* The key that is used to get the message can be set explicity by calling
setResourceKey.
* If that key is not explicitly set, it default to the pattern:
* [form-name].[component-name].[validator-class].
* For example:
*
* MyForm.name.RequiredValidator=A name is required.
*
* Error message string resources can contain optional ognl variable
interpolations from
* the component, such as:
*
* editBook.name.LengthValidator='${input}' is too short a name.
*
* Available variables for interpolation are:
*
* ${input} - The user's input
* ${name} - The name of the component
*
* but specific validator subclasses may add more values.
*
* @author Jonathan Locke
* @author Eelco Hillenius
*/
public abstract class AbstractValidator implements IValidator
{
/**
* Any set resource key. When it is not set, the validator uses it's
default
* message key.
*/
private String resourceKey;
/**
* Sets an error on the component being validated using the map
returned by
* messageModel() for variable interpolations.
*
* See class comments for details about how error messages are loaded
and formatted.
* @param formComponent form component
*/
public void error(FormComponent formComponent)
{
error(formComponent, messageModel(formComponent));
}
/**
* Returns a formatted validation error message for a given component.
The error
* message is retrieved from a message bundle associated with the page
in which this
* validator is contained using the given resource key. The
resourceModel is used for
* variable interpolation.
* @param formComponent form component
* @param resourceKey The resource key to use
* @param resourceModel The model for variable interpolation
*/
public void error(FormComponent formComponent, final String resourceKey,
final IModel resourceModel)
{
// Return formatted error message
Localizer localizer = formComponent.getLocalizer();
String message = localizer.getString(resourceKey,
formComponent, resourceModel);
formComponent.error(message);
}
/**
* Sets an error on the component being validated using the given map
for variable
* interpolations.
* @param formComponent form component
* @param resourceKey The resource key to use
* @param map The model for variable interpolation
*/
public void error(FormComponent formComponent, final String
resourceKey, final Map map)
{
error(formComponent, resourceKey, Model.valueOf(map));
}
/**
* Sets an error on the component being validated using the given map
for variable
* interpolations.
* @param formComponent form component
* @param map The model for variable interpolation
*/
public void error(FormComponent formComponent, final Map map)
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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 I want this, is that otherwise you can set the resourceKey, but
as any subclass can override the method, there is no way it is guaranteed it is
actually used.
Agreed?
Eelco
Eelco Hillenius wrote:
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, Version 2.0 (the "License"); you may not
* use this file except in compliance with the License. You may obtain a copy of
* the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations under
* the License.
*/
package wicket.markup.html.form.validation;
import java.util.HashMap;
import java.util.Map;
import wicket.Localizer;
import wicket.markup.html.form.FormComponent;
import wicket.model.IModel;
import wicket.model.Model;
import wicket.util.lang.Classes;
/**
* Base class for form component validators. This class is thread-safe and
therefore it is
* safe to share validators across sessions/threads.
*
* Error messages can be registered on a component by calling one of the
error(FormComponent ...)
* overloads. The error message will be retrieved using the Localizer for the
form
* component. Normally, this localizer will find the error message in a string
resource
* bundle (properties file) associated with the page in which this validator is
contained.
* The key that is used to get the message can be set explicity by calling
setResourceKey.
* If that key is not explicitly set, it default to the pattern:
* [form-name].[component-name].[validator-class].
* For example:
*
* MyForm.name.RequiredValidator=A name is required.
*
* Error message string resources can contain optional ognl variable
interpolations from
* the component, such as:
*
* editBook.name.LengthValidator='${input}' is too short a name.
*
* Available variables for interpolation are:
*
* ${input} - The user's input
* ${name} - The name of the component
*
* but specific validator subclasses may add more values.
*
* @author Jonathan Locke
* @author Eelco Hillenius
*/
public abstract class AbstractValidator implements IValidator
{
/**
* Any set resource key. When it is not set, the validator uses it's
default
* message key.
*/
private String resourceKey;
/**
* Sets an error on the component being validated using the map
returned by
* messageModel() for variable interpolations.
*
* See class comments for details about how error messages are loaded
and formatted.
* @param formComponent form component
*/
public void error(FormComponent formComponent)
{
error(formComponent, messageModel(formComponent));
}
/**
* Returns a formatted validation error message for a given component.
The error
* message is retrieved from a message bundle associated with the page
in which this
* validator is contained using the given resource key. The
resourceModel is used for
* variable interpolation.
* @param formComponent form component
* @param resourceKey The resource key to use
* @param resourceModel The model for variable interpolation
*/
public void error(FormComponent formComponent, final String resourceKey,
final IModel resourceModel)
{
// Return formatted error message
Localizer localizer = formComponent.getLocalizer();
String message = localizer.getString(resourceKey,
formComponent, resourceModel);
formComponent.error(message);
}
/**
* Sets an error on the component being validated using the given map
for variable
* interpolations.
* @param formComponent form component
* @param resourceKey The resource key to use
* @param map The model for variable interpolation
*/
public void error(FormComponent formComponent, final String
resourceKey, final Map map)
{
error(formComponent, resourceKey, Model.valueOf(map));
}
/**
* Sets an error on the
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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, Version 2.0 (the "License"); you may not
* use this file except in compliance with the License. You may obtain a copy of
* the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations under
* the License.
*/
package wicket.markup.html.form.validation;
import java.util.HashMap;
import java.util.Map;
import wicket.Localizer;
import wicket.markup.html.form.FormComponent;
import wicket.model.IModel;
import wicket.model.Model;
import wicket.util.lang.Classes;
/**
* Base class for form component validators. This class is thread-safe and therefore it is
* safe to share validators across sessions/threads.
*
* Error messages can be registered on a component by calling one of the error(FormComponent ...)
* overloads. The error message will be retrieved using the Localizer for the form
* component. Normally, this localizer will find the error message in a string resource
* bundle (properties file) associated with the page in which this validator is contained.
* The key that is used to get the message can be set explicity by calling setResourceKey.
* If that key is not explicitly set, it default to the pattern:
* [form-name].[component-name].[validator-class].
* For example:
*
* MyForm.name.RequiredValidator=A name is required.
*
* Error message string resources can contain optional ognl variable interpolations from
* the component, such as:
*
* editBook.name.LengthValidator='${input}' is too short a name.
*
* Available variables for interpolation are:
*
* ${input} - The user's input
* ${name} - The name of the component
*
* but specific validator subclasses may add more values.
*
* @author Jonathan Locke
* @author Eelco Hillenius
*/
public abstract class AbstractValidator implements IValidator
{
/**
* Any set resource key. When it is not set, the validator uses it's default
* message key.
*/
private String resourceKey;
/**
* Sets an error on the component being validated using the map returned by
* messageModel() for variable interpolations.
*
* See class comments for details about how error messages are loaded and formatted.
* @param formComponent form component
*/
public void error(FormComponent formComponent)
{
error(formComponent, messageModel(formComponent));
}
/**
* Returns a formatted validation error message for a given component. The error
* message is retrieved from a message bundle associated with the page in which this
* validator is contained using the given resource key. The resourceModel is used for
* variable interpolation.
* @param formComponent form component
* @param resourceKey The resource key to use
* @param resourceModel The model for variable interpolation
*/
public void error(FormComponent formComponent, final String resourceKey,
final IModel resourceModel)
{
// Return formatted error message
Localizer localizer = formComponent.getLocalizer();
String message = localizer.getString(resourceKey, formComponent, resourceModel);
formComponent.error(message);
}
/**
* Sets an error on the component being validated using the given map for variable
* interpolations.
* @param formComponent form component
* @param resourceKey The resource key to use
* @param map The model for variable interpolation
*/
public void error(FormComponent formComponent, final String resourceKey, final Map map)
{
error(formComponent, resourceKey, Model.valueOf(map));
}
/**
* Sets an error on the component being validated using the given map for variable
* interpolations.
* @param formComponent form component
* @param map The model for variable interpolation
*/
public void error(FormComponent formComponent, final Map map)
{
error(formComponent, getResourceKey(formComponent), Model.valueOf(map));
}
/**
* Explicitly set the resource key that should be used.
* WARNING: as resourceKey() is overrable, setting this parameter does not guarantee
* that extending validators honor using it.
* @param resourceKey the resource key
*/
public final void setResourceKey(String resourceKey)
{
this.resourceKey = resourceKey;
}
/**
* Returns the explicitly set resource key or null when it was not set explicitly.
* @return the explicitly set resource key or null
*/
protected final String getResourceKey()
{
return resourceKey;
}
/**
* Gets the resource key based on the form component
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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 RequiredValidator. Pretty wrong though. Oops. Another reason to fix this. I'm from +0 to +1. Eelco On 7/20/05, Erik van Oosten <[EMAIL PROTECTED]> wrote: +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 sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
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 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 sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > ___ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
RE: [Wicket-user] VOTE: make AbstractValidator threadsafe
+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 AbstractValidator threadsafe > > +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 sponsored by: Discover Easy Linux Migration > Strategies from IBM. Find simple to follow Roadmaps, > straightforward articles, informative Webcasts and more! Get > everything you need to get up to speed, fast. > http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > ___ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
RE: [Wicket-user] VOTE: make AbstractValidator threadsafe
+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 sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
RE: [Wicket-user] VOTE: make AbstractValidator threadsafe
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 is 'ugly' to carry the parameter around, but there current version is a lot uglier. The code is complicated to understand and it locks the complete system. So if there are a lot of users that use the validator.. the single instance (Validators ca be singletons) has to be locked by each client multiple times. And offcource.. there are a lot of methods that don`t make sense and have vague concurrency semantics. I would call the removal of the locking and better concurrency semantics a big improvement. It would however make AbstractValidator thread safe, and it makes implementing IValidator from scratch maybe a bit easier (IValidator has to change too for this change to work). __ The IValidator doesn`t have to change. The interface remains the same, only the documentation of 'needs to be synchronized' has to be removed. Btw I`m not going to use the current validators anyway. I`m developing a set of Validators that are more consistent and easier to use. Maybe my company is going to make it opensource so everyone can use them. I'm +0 I`m +100 *hopes nobody has the idea to vote against with a bigger number* Eelco --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user <>
Re: [Wicket-user] VOTE: make AbstractValidator threadsafe
+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 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 would however make AbstractValidator thread safe, and it makes implementing IValidator from scratch maybe a bit easier (IValidator has to change too for this change to work). I'm +0 Eelco --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
