I would most like want this to be built against the JPA spec instead
of directly implementing Hibernate's validators. Then we can use it
for toplink, hibernate, openjpa, etc. And it is Apache license
friendly too.
Martijn
On 4/25/07, Bruno Borges [EMAIL PROTECTED] wrote:
I was thinking of a
I haven't had time to check HV in depth for the moment but I've heard
good things about it, and was about to ask the same question as Bruno,
because I would be interested too in such a validator.
Martijn, doesn't your proposition to rely on JPA spec instead of HV
imply to rewrite sg similar to
Sorry.. worst than Draft Review: JSR 303 is in Draft Ballot yet!! So it'll
take some time until a final specification for this under JPA. :(
Let's continue with HV ? :D
[]'s
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 4/25/07, Bruno Borges [EMAIL
On 4/25/07, Bruno Borges [EMAIL PROTECTED] wrote:
Sorry.. worst than Draft Review: JSR 303 is in Draft Ballot yet!! So it'll
take some time until a final specification for this under JPA. :(
Let's continue with HV ? :D
It seems reasonable to me, but the opinion from Wicket team would be
much
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
and if you do your port now from 2.0 to 1.3
then you could maybe point us to a feature that was in 2.0 but is overlooked
by use to backport
johan
On 4/24/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
OK, thanks a lot.
Martijn Dashorst wrote:
You can track the backports on the wiki:
Hi,
I found an error in wicket-contrib-scriptaculous-examples/pom.xml. It
has a dependency to wicket-contrib-scriptaculous (of course), but the
group ID should be 'org.wicketstuff', not 'wicket-stuff'.
I guess the group ID renamed, and you all have a version for the old
group id in your
I think that blatant errors can be fixed by anyone with write access.
In this particular case it should not lead to discussion :)
Complete rewrites of functionalities is something that should be
discussed before undertaken, even by 'project owners'. This is because
we're trying to build a
I am now porting our code, and already came across a number of issues:
* no longer support for alternate parents
* MarkupContainer.add() (where we could implement our own alternate parent
logic) is final
* Component.getModel() is now final
When I get all code ported debugged, I will point out
why would our opinion matter? you are free to start a wicket-stuff project
to integrate whatever you want :)
-igor
On 4/25/07, Xavier Hanin [EMAIL PROTECTED] wrote:
On 4/25/07, Bruno Borges [EMAIL PROTECTED] wrote:
Sorry.. worst than Draft Review: JSR 303 is in Draft Ballot yet!! So
it'll
i am planning on backporting ialternateparentprovider still. of course if
you want to beat me to it with a patch you are most welcome.
-igor
On 4/25/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
I am now porting our code, and already came across a number of issues:
* no longer support for
so its foo, bar, kazam. interesting.
-igor
On 4/25/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
I think that blatant errors can be fixed by anyone with write access.
In this particular case it should not lead to discussion :)
Complete rewrites of functionalities is something that should be
As I see it, it could be implemented MarkupContainer, looking for an
interface IAlternateParentProvider when add() is called, and add it to the
parent returned by getAlternateParent(). I don't know if the alternateParent
logic should also apply for replace remove.
Jan.
igor.vaynberg wrote:
Johan Compagner wrote:
typecast? in 2.0 you didn't have to cast when using the model or
getModelObject()
where did you need to cast?
I'm not referring to the object of the model, but to the model itself: we
have extended models that implement specific interfaces that allow other
jdk1.4 doesnt have covariant return types anyways. when we move to jdk
1.5you can bring this up again :)
-igor
On 4/25/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
Johan Compagner wrote:
typecast? in 2.0 you didn't have to cast when using the model or
getModelObject()
where did you need
+1 for just getting something working. use wicket-stuff for now and
worry about licensing *if* it works well enough to try and push into
the core.
On 4/25/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
why would our opinion matter? you are free to start a wicket-stuff project
to integrate whatever
naah, we share this list with wicket-stuff. makes it easier.
-igor
On 4/25/07, Xavier Hanin [EMAIL PROTECTED] wrote:
On 4/25/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
why would our opinion matter? you are free to start a wicket-stuff
project
to integrate whatever you want :)
Agreed, but
We have 12 PPMC members and 4 mentors. Until now we have had 1 vote
from a PPMC member and one from a mentor. Can we get some weight
behind this release please?
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6
I didn't run rat, but a manual check looked good to me.
+1
Eelco
On 4/25/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
We have 12 PPMC members and 4 mentors. Until now we have had 1 vote
from a PPMC member and one from a mentor. Can we get some weight
behind this release please?
Martijn
--
i thought we have the three required votes for it to pass
yours, bertrand's, and frank's
so as long as no one votes -1 we are set no?
On 4/25/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
We have 12 PPMC members and 4 mentors. Until now we have had 1 vote
from a PPMC member and one from a
Given the importance of this release to the Wicket project and our
goal of graduation I expected more enthousiasm/commitment from both
the PPMC *and* the mentors.
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket
On 4/25/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Can we get some weight
behind this release please?...
I second this request - a larger number of positive binding votes (and
non-binding votes from community members are also ok) is certainly a
good sign for Incubator PMC members who
On 4/25/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
naah, we share this list with wicket-stuff. makes it easier.
Ok, sorry, next time I'll just put a +1 to give my opinion, it will
save a couple of emails :-)
Xavier
-igor
On 4/25/07, Xavier Hanin [EMAIL PROTECTED] wrote:
On 4/25/07, Igor
On 4/25/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Given the importance of this release to the Wicket project and our
goal of graduation I expected more enthousiasm/commitment from both
the PPMC *and* the mentors
Yes! Mentors, let's graduate this baby so that we can be out of here!
I don't think I undestand the issue...
Eelco
On 4/25/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
-- Forwarded message --
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Apr 25, 2007 5:37 AM
Subject: MarkupParserFactory
To: [EMAIL PROTECTED]
Hello!
I think you have a little bug
Bertrand Delacretaz wrote:
On 4/25/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Given the importance of this release to the Wicket project and our
goal of graduation I expected more enthousiasm/commitment from both
the PPMC *and* the mentors
Yes! Mentors, let's graduate this baby so that
Did this change fall of the charts from the backport lists? Must we
change the logging to SF$#L@@#4j or can we live with commons-logging?
Martijn (who hasn't been bitten with clogging, yet)
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net:
What are the expectations for the Wicket BoF at ApacheCon?
Are we deciding on site what to do? Or is some preparation involved,
i.e. introducing Wicket, etc?
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6
Hi Martijn,
Wednesday, April 25, 2007, 5:25:26 PM, you wrote:
We have 12 PPMC members and 4 mentors. Until now we have had 1 vote
from a PPMC member and one from a mentor. Can we get some weight
behind this release please?
+1 to release here.
Did a quick scan over all seemed well - was
Personnaly I prefer slf4j, especially because it doesn't suffer from
classloading issues.
My 2c.
Xavier
On 4/25/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Don't care personally.
Eelco
On 4/25/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Did this change fall of the charts from the
Thanks for your vote!
On 4/25/07, Sylvain Wallez [EMAIL PROTECTED] wrote:
- it would be nice to have NOTICE, README, etc have a .txt extension
for those people that use a graphical file browser.
The reason they are without .txt is because otherwise we would get 2:
one without .txt and one
I also prefer slf4j (non-binding, of course). slf4j does not suffer
from the classloading issues and, in my experience, is a quick and easy
replacement for commons-logging.
On Wed, 2007-04-25 at 21:42 +0200, Xavier Hanin wrote:
Personnaly I prefer slf4j, especially because it doesn't suffer
Martijn Dashorst wrote:
Thanks for your vote!
On 4/25/07, Sylvain Wallez [EMAIL PROTECTED] wrote:
- it would be nice to have NOTICE, README, etc have a .txt extension
for those people that use a graphical file browser.
The reason they are without .txt is because otherwise we would get 2:
On 4/25/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 4/25/07, Sylvain Wallez [EMAIL PROTECTED] wrote:
-... the NOTICE file is in my opinion overzealous
This is also our administration for external libs :), and prevents
recurring questions when someone new looks at the files
+1... lol :D
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 4/25/07, Bertrand Delacretaz [EMAIL PROTECTED] wrote:
On 4/25/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 4/25/07, Sylvain Wallez [EMAIL PROTECTED] wrote:
-... the NOTICE file
We also have components with our own getModel implementation because of special
Models that extend Imodel and it would be very hard for us to go around this if
getModel is final.
Stefan Lindner
-Ursprüngliche Nachricht-
Von: Jan Vermeulen [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch,
If you are really, really sure overriding getModel is the only
reasonable way to go, we can consider not having it final and put a
big warning in the docs instead. However, this is such a core feature
that we really wouldn't want people to get the wrong idea. Are you
sure there is no acceptable
37 matches
Mail list logo
