Eelco Hillenius wrote:
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
2. Do the constructor change in a seperate release (Wicket 1.3) and
put Java 5 in the next (Wicket 2.0)
3. I don't want either one and I want to stay on Wicket 1.2.
I vote for #2
I vote for #1. I want the latest and greatest -- thats why I'm into wicket!
/Fredrik
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching
#QuoteI vote for 2. 2. Do the constructor change in a seperate release (Wicket 1.3) andput Java 5 in the next (Wicket 2.0)On 2/16/06,
Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Hi all,This is a non-binding (the developers ultimately decide) call votesconcerning whether we should fold the upcommin
> 1. Give me the constructor change and the Java 5 functionality in one> pass (Wicket 2.0)+1
-- "The more life's risk you take, the more life's reward you get" - Me
#1 is my vote too.
Regards,
Abdullah
--- Cameron Taggart <[EMAIL PROTECTED]> wrote:
> I vote for #1. I am already running Java 5 and it sounds like a 1.3
> release with the constructor change may delay work on Java 5.
>
> cheers,
> Cameron
>
> On 2/16/06, Eelco Hillenius <[EMAIL PROTECTED]> w
On Feb 16, 2006, at 5:33 PM, Eelco Hillenius wrote:
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
+1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?
2/ +1 (separate releases).
./alex
--
.w( the_mindstorm )p.
On 2/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> This is a non-binding (the developers ultimately decide) call votes
> concerning whether we should fold the upcomming constructor changes
> with our move to Java 5 or n
+1 on option 1.On 2/18/06, Cameron Taggart <[EMAIL PROTECTED]> wrote:
I vote for #1. I am already running Java 5 and it sounds like a 1.3release with the constructor change may delay work on Java 5.cheers,CameronOn 2/16/06, Eelco Hillenius <
[EMAIL PROTECTED]> wrote:> Hi all,>> This is a non-bindi
I vote for #1. I am already running Java 5 and it sounds like a 1.3
release with the constructor change may delay work on Java 5.
cheers,
Cameron
On 2/16/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> This is a non-binding (the developers ultimately decide) call votes
> concerning
2. Do the constructor change in a seperate release (Wicket 1.3) andput Java 5 in the next (Wicket 2.0)I would like to see the constructor change as soon as possible, as it is a bit of a thorn in the paw when using wicket. Watching the cvs commits, the rate of development on wicket is impressive. I'
+1 to option 1On 2/17/06, Justin Lee <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-Hash: RIPEMD160w00t!> 1. Give me the constructor change and the Java 5 functionality in one> pass (Wicket 2.0)- --Justin Lee
http://www.antwerkz.comAIM : evan chooly720.299.0101-BEGIN PGP SIGNATURE
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
w00t!
> 1. Give me the constructor change and the Java 5 functionality in one
> pass (Wicket 2.0)
- --
Justin Lee
http://www.antwerkz.com
AIM : evan chooly
720.299.0101
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFD9kfKJn
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
Bryn
Gili wrote:
On Feb 17, 2006, at 3:33 AM, Eelco Hillenius wrote:
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
+1.
Gili
-
Vote:
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
+1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
se
#2. Java 5 still does not run on all hardware that Java 1.4 runs on.
AIX is one good example. And are all Java web hosters running Java 5
yet?
- Jonathan
>>> [EMAIL PROTECTED] 2006-02-16 7:33:37 PM >>>
Hi all,
This is a non-binding (the developers ultimately decide) call votes
concerning wh
On Feb 16, 2006, at 6:33 PM, Eelco Hillenius wrote:
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
+1
-jason
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for pro
Vote:
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that make
I vote for option 1.
On Thu, 2006-02-16 at 17:33 -0800, Eelco Hillenius wrote:
> Hi all,
>
> This is a non-binding (the developers ultimately decide) call votes
> concerning whether we should fold the upcomming constructor changes
> with our move to Java 5 or not. See for a discussion of those ch
> 1. Give me the constructor change and the Java 5 functionality in one
> pass (Wicket 2.0)
+1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
2. Do the constructor change in a seperate release (Wicket 1.3) and
put Java 5 in the next (Wicket 2.0)
Walter
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eelco
Hillenius
Sent: Friday, February 17, 2006 2:34 AM
To: Wicket User List
Subject: [Wicket-us
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
-Matej
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that m
1. Same
pepone pepone wrote:
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
On 2/17/06, John Patterson <[EMAIL PROTECTED]> wrote:
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
In the hope that we
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
On 2/17/06, John Patterson <[EMAIL PROTECTED]> wrote:
> 1. Give me the constructor change and the Java 5 functionality in one
> pass (Wicket 2.0)
>
> In the hope that we will have both sooner.
>
> On Thursday 1
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
In the hope that we will have both sooner.
On Thursday 16 Feb 2006 21:33, Eelco Hillenius wrote:
> Hi all,
>
> This is a non-binding (the developers ultimately decide) call votes
> concerning whether we should
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
--
Joni Suominen <[EMAIL PROTECTED]>
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the n
+1 on 2except if weaver or translater really works. Then i guess i can live with that for a while.Because backporting stuff from 2.0 to 1.3 would be much easier then from 2.0 to 1.2And i don't think i can force all customers to use
1.5 on the server this year.johanOn 2/17/06, Eelco Hillenius <[EMA
> 2. Do the constructor change in a seperate release (Wicket 1.3) and
> put Java 5 in the next (Wicket 2.0)
+1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search e
+1
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
cheers,
Adam Chesney
Head of Core Development
Multicom Products Ltd
=
Tel: (+44) 117 908 1254 (Direct)
Mobile (+44) 7780 962 961
email: [EMAIL PROTE
A vote for:
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
Regards,
Erik.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJ
+1
> 2. Do the constructor change in a seperate release (Wicket 1.3) and
> put Java 5 in the next (Wicket 2.0)
>
Shumbola
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new
Vote for 2.
On 2/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> This is a non-binding (the developers ultimately decide) call votes
> concerning whether we should fold the upcomming constructor changes
> with our move to Java 5 or not. See for a discussion of those changes
> other
1. Give me the constructor change and the Java 5 functionality in onepass (Wicket 2.0) +1 <|>Per EjeklintMobile: +46 (0)70-5090052Web: http://www.ejeklint.seSkype: callto://ejeklint
I second that:
+1 on separate releases for constructor change and Java 5 support.
Personally I wouldn't mind if you guys pulled up the constructor change into
1.2 - IMHO this is most important and we should get over it as soon as possible.
Then version 2.0 could concentrate on Java 5 - while st
Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
Cheers
Dipu
- Original Message -
From: "Eelco Hillenius" <[EMAIL PROTECTED]>
To: "Wicket User List"
Sent: Friday, February 17, 2006 1:33 AM
Subject: [Wicket-user] VOTE
Hi all,
This is a non-binding
Hello,
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
+1
Best regards,
Piotr
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
Ari S.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that
2. Do the constructor change in a seperate release (Wicket 1.3) and
put Java 5 in the next (Wicket 2.0)
The constructor change is a major change. Would you rather support an
old and different version (1.2), or an old version that is much closer
in a major way to the 'current' version?
I vot
+1 for
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that
+11. Give me the constructor change and the Java 5 functionality in onepass (Wicket 2.0)
Relax. Yahoo! Mail
virus scanning helps detect nasty viruses!
On Feb 17, 2006, at 3:33 AM, Eelco Hillenius wrote:
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
+1.
Gili
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for probl
2006/2/17, Eelco Hillenius [EMAIL PROTECTED]:
2. Do the constructor change in a seperate release (Wicket 1.3) andput Java 5 in the next (Wicket
2.0)
+1
Dirk
#1. Better to have to make major changes once.--AndrewOn 2/17/06, Janne Hietamäki <[EMAIL PROTECTED]
> wrote:On Feb 17, 2006, at 3:33 AM, Eelco Hillenius wrote:>> 1. Give me the constructor change and the Java 5 functionality in one
> pass (Wicket 2.0)+1.We are still forced to run Java 1.4, but I'
On Feb 17, 2006, at 3:33 AM, Eelco Hillenius wrote:
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
+1.
We are still forced to run Java 1.4, but I'm testing if
retrotranslator is stable enough for production.
--
Janne Hietamäki
Cemron Ltd
http://ww
´+1
2. Do the constructor change in a seperate release (Wicket 1.3) and
put Java 5 in the next (Wicket 2.0)
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX sear
Eelco Hillenius schrieb:
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX sea
I can't speak for everyone else, but if you have to upgrade your
application for the constructor changes, why not upgrade to java5
while your at it? - Don't answer that :) ... I prefer both in one
shot.
Vote #1
---
This SF.net email is sponsor
I vote for 2. 2. Do the constructor change in a seperate release (Wicket 1.3) andput Java 5 in the next (Wicket 2.0)
雅虎1G免费邮箱百分百防垃圾信
雅虎助手-搜索、杀毒、防骚扰
> 2. Do the constructor change in a seperate release (Wicket 1.3) and
> put Java 5 in the next (Wicket 2.0)
Otherwise, I'll be stuck with 1.2 for a lng time. I'm more than
happy to move to 1.3, but due to reasons beyond my control, cannot yet
make the jump to Java 5 for some time to come.
1. Give me the constructor change and the Java 5 functionality in onepass (Wicket 2.0)On 2/17/06, Eelco Hillenius <
[EMAIL PROTECTED]> wrote:> my 2 cents is to keep the core 1.4 compatable and have java
1.5 as an> addon (like tapestry, hibernate and several other projects).That is not possible unf
> my 2 cents is to keep the core 1.4 compatable and have java 1.5 as an
> addon (like tapestry, hibernate and several other projects).
That is not possible unfortunately. One of the main things we'll apply
1.5 on is the IModel interface. There is just no way to seperate that.
Eelco
2. keep them seperate.
my 2 cents is to keep the core 1.4 compatable and have java 1.5 as an
addon (like tapestry, hibernate and several other projects).
On 2/16/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>
> > 1. Give me the constructor change and the Java 5 functionality in one
> > pass (Wic
1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)-Igor
On 2/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
1. Give me the constructor change and the Java 5 functionality in onepass (Wicket 2.0)I vote both at once. Given the discussions about not everyone moving to 5, and the fact that the constructor change will be a MAJOR change affecting not just
+1
Hi Eelco,
Sorry I did not respond before on the list topic. I know too little about
Wicket, and you were just faster.
Thanks for proposing it,
Christian
On Fri, 29 Jul 2005 18:48:51 +0200, Eelco Hillenius
<[EMAIL PROTECTED]> wrote:
I think we should remove these methods. They are quite
+1
Eelco Hillenius wrote:
I think we should remove these methods. They are quite easy to
implement yourself, and they limit the ways we can change ListView's
internals.
I can see they are 'handy', but I feel they also mess up the idea that
a low level component should be one thing at a time.
+1
I've allways wondered why are they there :)
-Matej
Eelco Hillenius wrote:
I think we should remove these methods. They are quite easy to implement
yourself, and they limit the ways we can change ListView's internals.
I can see they are 'handy', but I feel they also mess up the idea that a
+1
-Igor
---
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://a
Yea, I always wondered what the were there for. They seem like clutter to me.
+1
On 7/29/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> I think we should remove these methods. They are quite easy to implement
> yourself, and they limit the ways we can change ListView's internals.
>
> I can see
that is not an option (using generics)
i think this will be an option After 1.2 not earlier because wicket is a
framework that will be used on servers
and servers are pretty slow to adapt to new java versions.
Especially things like Websphere where versions are build on a specific jvm
I will ad
+1 the javadoc should be clear that the underlying model object needs to be
a list or whatever. It would be nice to switch to imodel right now.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Johan Compagner
> Sent: Friday, July 29, 2005 4:33 AM
+/- 0 (+1)
I like the option discussed in the wicket 1.1b2-rc1 string.
keep both and make the old one deprecated.
But if you can't have both, then break
Johan Compagner wrote:
> We now have:
>
> public AbstractChoice(final String id, IModel model, final List
> choices, final IChoiceRenderer ren
+1
Juergen
On 7/29/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> +1
>
> Eelco
>
>
> Johan Compagner wrote:
>
> > We now have:
> >
> > public AbstractChoice(final String id, IModel model, final List
> > choices, final IChoiceRenderer renderer)
> >
> > I want to change it to:
> >
> > public
+1
Eelco
Johan Compagner wrote:
We now have:
public AbstractChoice(final String id, IModel model, final List
choices, final IChoiceRenderer renderer)
I want to change it to:
public AbstractChoice(final String id, IModel model, final IModel
choices, final IChoiceRenderer renderer)
So t
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
101 - 191 of 191 matches
Mail list logo
