On Tue, 19 Jun 2007, Igor Vaynberg wrote:
dont know if we need a separate wicket-ioc which wont be very useful by
itself, we could just move that stuff into extensions.
I think that it would be very useful by itself (as a possible
proxified version of @Configurable of Spring) and even without
Sorry, you are quite right, I must have used the mergere repo for some
other dependencies. I checked and we too have jta on our company repo,
so that is how i got it.
Sorry for the mix up.
Maurice
On 6/20/07, Ryan Sonnek [EMAIL PROTECTED] wrote:
not sure how you got this to work. the
I understand, and yes it makes sense. Validation, and the order in which it
should be invoked, is a complex theme, and we have been struggling with it
for a while too.
We make a distinction between syntactic and semantic (business) validation:
syntactic validation should happen before
Let me try to explain:
First, we have a way of gathering 'constraints' for bean properties, that
are based either on validator annotations on the bean, or on a settings
environment (the beanClass propertyPath are derived from the model of the
formComponent). The endresult is a list of
I did some new experiments, and I know what is the problem:
The classloader only finds the 'wicket.properties' file, when it's in the
classpath of that classloader. And the classloader used here is:
Application.initializeComponents() {
...
... getClass().getClassLoader()
...
}
So
From the Application#destroy() javadoc:
/**
* Called when wicket servlet is destroyed.
* Overrides do not have to call super.
*/
protected void destroy()
{
callDestroyers();
}
That's not ideal - surely we want to be certain the destroyers are called?
I think we should make this method
Howdy,
Application#internalInit() isn't final. However, if you override it and
don't call super.internalInit(), you won't add the session store, the
converter locator, any of the component resolvers, etc. etc.
Obviously you have the init() method to configure your app with. So
surely
Jan Vermeulen wrote:
So my question is now: is that 'wicket.properties' file meant to be a
resource that's always within the Wicket 'bundle' ? If so, would it not be
better to use the latter code to lookup resources, so that it works in
environments with multiple classloaders ?
Yes, it will
Al Maw wrote:
Application#internalInit() isn't final. However, if you override it and
don't call super.internalInit(), you won't add the session store, the
converter locator, any of the component resolvers, etc. etc.
Obviously you have the init() method to configure your app with. So
surely
Timo Rantalaiho wrote:
On Tue, 19 Jun 2007, Igor Vaynberg wrote:
dont know if we need a separate wicket-ioc which wont be very useful by
itself, we could just move that stuff into extensions.
I think that it would be very useful by itself (as a possible
proxified version of @Configurable of
+1
On 6/20/07, Al Maw [EMAIL PROTECTED] wrote:
From the Application#destroy() javadoc:
/**
* Called when wicket servlet is destroyed.
* Overrides do not have to call super.
*/
protected void destroy()
{
callDestroyers();
}
That's not ideal - surely we want to be certain the destroyers
I'd rather not put it in a separate project. The number of sub
projects is growing again and if we can provide a way to maximize
reuse of project infrastructure, then I'm for that.
I tried looking in the archives for a discussion on moving them into
extensions, but didn't find it. I guess the
I followed that http://wicket.sourceforge.net/ file.
But How i install and run jetty.
Can i work wicket framework with Tomcat Server...? Is it possible..
other wise give me correct url.
Thanks in advance.
Thanks Regards
kumar
--
View this message in context:
Actually there is also a protected internalDestroy (still not final
though) which calls destroy so why not put callDestroyers there ?
Maurice
On 6/20/07, Sean Sullivan [EMAIL PROTECTED] wrote:
+1
On 6/20/07, Al Maw [EMAIL PROTECTED] wrote:
From the Application#destroy() javadoc:
/**
*
It works with the classloader of the current thread, so that's OK.
And yes, I was surprised to find a non-optional initialization like that of
the PropertyResolver to be defined in an Initializer that might not always
be called. So 100% correct to move that to an internalInit.
Jan.
--
View
http://cwiki.apache.org/WICKET/newuserguide.html
Maybe it's easier to try a wicket 1.3 beta release:
http://people.apache.org/dist/incubator/wicket/apache-wicket-1.3.0-incubating-beta1/dist/
Wicket uses Maven2 a lot, it would be best to download and install that one
too!
Yes, you can use
can't we call the class resolver? for this?
OSGI is supposed to implement this and then the defaults are also better
johan
On 6/20/07, Al Maw [EMAIL PROTECTED] wrote:
Jan Vermeulen wrote:
So my question is now: is that 'wicket.properties' file meant to be a
resource that's always within
and that all makes perfect sense, however at its current state the
requried/null checks are considered syntactic checks. if not then every
ivalidator out there must first perform the null check, which is annoying.
how about:
class ConstraintValidator extends ... implments IValidatorAddListener
yes, that makes sense. howevern, i still like ondestroy() better then
destroy(). ondestroy() makes it clear it is a listener.
-igor
On 6/20/07, Maurice Marrink [EMAIL PROTECTED] wrote:
Actually there is also a protected internalDestroy (still not final
though) which calls destroy so why not
On 6/20/07, Jan Vermeulen [EMAIL PROTECTED] wrote:
It works with the classloader of the current thread, so that's OK.
And yes, I was surprised to find a non-optional initialization like that
of
the PropertyResolver to be defined in an Initializer that might not always
be called.
erm.
do i need a vote to make this change at this point?
Eelco Hillenius wrote:
It might be good to be more defensive here then (as I think the trace I
got
had lost the info in both places): We could turn
Strings.toString(Throwable)
back into a simple version that always gives you the entire
i still don't get it what then should be changed
We are printing the complete stack..
the root cause is completely printed. Only the exceptions around the root
cause is not completely printed. (those are stopped at the wicket
servlet/filter)
johan
On 6/20/07, Jonathan Locke [EMAIL PROTECTED]
Whatever makes you happy :)
I see Johan as has already made the change of putting callDestroyers
in internalDestroy.
However if you are going to rename that method (not sure if Martijn is
going to like that this late in the game). Please let us know since
those projects still on jdk 1.4 don't
On 6/20/07, Maurice Marrink [EMAIL PROTECTED] wrote:
Whatever makes you happy :)
I see Johan as has already made the change of putting callDestroyers
in internalDestroy.
However if you are going to rename that method (not sure if Martijn is
going to like that this late in the game). Please let
as in ?
protected void internalDestroy()
{
...
destroy();
...
}
public final void destroy()
{
ondestroy();
}
public void ondestroy()
{
//do some cleanup here
}
bah, i'd rather have the rename. I have absolutly no problem with a
rename as long as it is announced on the mailing list. But i don't
We have Graduation! Apache Wicket is established as a top level
project within the Apache Software Foundation.
From Greg Stein:
Original Message
Subject: Apache Board Meeting, June 20, 2007 (new officers!)
Date: Wed, 20 Jun 2007 12:45:06 -0700
Congratulations to everyone for making Apache Wicket a success.
Maurice
On 6/20/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
We have Graduation! Apache Wicket is established as a top level
project within the Apache Software Foundation.
From Greg Stein:
Original Message
bah, i'd rather have the rename. I have absolutly no problem with a
rename as long as it is announced on the mailing list.
That's fine. But I have :). And I have been bitten by it enough to
know that without such a deprecation realease, people *will* forget/
not notice.
Eelco
actually
protected void internaldestroy() { ondestroy(); }
@deprecated - use ondestroy instead
final void destroy() {}
void ondestroy() {}
-igor
On 6/20/07, Maurice Marrink [EMAIL PROTECTED] wrote:
as in ?
protected void internalDestroy()
{
...
destroy();
...
}
public final void destroy()
Ok, i see i misunderstood, this i can live with. fwiw :)
Maurice
On 6/20/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
actually
protected void internaldestroy() { ondestroy(); }
@deprecated - use ondestroy instead
final void destroy() {}
void ondestroy() {}
-igor
On 6/20/07, Maurice Marrink
Congratulations to you and the team for making it through the
incubator to TLP.
Craig
Begin forwarded message:
From: Greg Stein [EMAIL PROTECTED]
Date: June 20, 2007 12:45:06 PM PDT
To: [EMAIL PROTECTED]
Subject: Apache Board Meeting, June 20, 2007 (new officers!)
Reply-To: [EMAIL
Congrats ;-)
On 6/21/07, Maurice Marrink [EMAIL PROTECTED] wrote:
Congratulations to everyone for making Apache Wicket a success.
+0
The Javadoc says: A button that submits the form via ajax. And
the callback method is called onSubmit().
So even if you rename the class (which is a very costly operation
in a framework), it won't be sufficient to eradicate the term
submit.
I understand that you want to streamline
A well deserved congratulations go out to all of the team! I'd love to buy
you all a round of beers (or the drink of your choice)! =)
On 6/20/07, Mark Derricutt [EMAIL PROTECTED] wrote:
Congrats ;-)
On 6/21/07, Maurice Marrink [EMAIL PROTECTED] wrote:
Congratulations to everyone for
i just want to change the code so that Strings.toString(throwable) does not
do this.
we can move this stack trace trimming code into the exception page. that
way we're
100% sure that it will never mess up.
i think at least one of the truncated stack traces i've found was caused by
Great! Congrats to a job well done! :)
On 6/20/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
We have Graduation! Apache Wicket is established as a top level
project within the Apache Software Foundation.
From Greg Stein:
Original Message
Subject: Apache Board
Jean-Baptiste Quenot wrote:
+0
The Javadoc says: A button that submits the form via ajax. And
the callback method is called onSubmit().
So even if you rename the class (which is a very costly operation
in a framework), it won't be sufficient to eradicate the term
submit.
I understand
[ x ] Yes, rename AjaxSubmitButton to AjaxButton, leaving behind a
@deprecated subclass for backwards-compatibility.
[ ] No, that's a crazy idea. We're frozen for 1.3.0 and this sort of
stuff shouldn't change this late in the day.
Eelco
I've given this thread a little bit thought, and besides the
objections Martijn and me have regarding the book, I don't think I
like SubmitButton better than Button. To me, a Button is more generic
and SubmitButton makes me think about 'just' the input type=submit
tag while it can be used for
Eelco Hillenius wrote:
[ x ] Yes, rename AjaxSubmitButton to AjaxButton, leaving behind a
@deprecated subclass for backwards-compatibility.
[ ] No, that's a crazy idea. We're frozen for 1.3.0 and this sort of
stuff shouldn't change this late in the day.
OK, this is done, along with
maybe the exception display page should just hide all the extra details
using a javascript
triggered fold-out instead of trying to programmatically remove it?
That would be nice.
Eelco
Eelco Hillenius wrote:
I've given this thread a little bit thought, and besides the
objections Martijn and me have regarding the book, I don't think I
like SubmitButton better than Button. To me, a Button is more generic
and SubmitButton makes me think about 'just' the input type=submit
tag
Hi,
I just came across this:
http://cwiki.apache.org/WICKET/using-gwt-widgets-as-wicket-components-tutorial.html
Did someone ever did that? Is it a good idea to have such integration
rather than just running GWT as an applet? And if this is a good idea,
how about putting this in a Wicket-stuff
neat - congrats all round!
On 21/06/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
We have Graduation! Apache Wicket is established as a top level
project within the Apache Software Foundation.
From Greg Stein:
Original Message
Subject: Apache Board Meeting,
i wondered about this a while ago. it's like the return of sprockets.
only this time they're googly. i think it's a very interesting
idea to play with. it should certainly be a wicket-stuff project
if someone wants to work on it.
Eelco Hillenius wrote:
Hi,
I just came across this:
btw, i think GwtWidgetComponent should really be called something with Panel
in it so people don't think it's a Component. maybe GwtPanel?
Eelco Hillenius wrote:
Hi,
I just came across this:
http://cwiki.apache.org/WICKET/using-gwt-widgets-as-wicket-components-tutorial.html
Did
46 matches
Mail list logo
