sure, i'll resolve it just after anyone confirm that the thing finally works :)
-Matej
On 3/14/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote:
* [EMAIL PROTECTED]:
> Author: knopp
> Date: Wed Mar 14 09:45:14 2007
> New Revision: 518211
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=5182
+1 (binding)
-Matej
On 3/15/07, Frank Bille <[EMAIL PROTECTED]> wrote:
I totally agree. I have also started a release wiki page where I try to
collect the information about the legals we have been going through and
solved.
http://cwiki.apache.org/confluence/display/WICKET/Wicket+1.3.0+incubati
I totally agree. I have also started a release wiki page where I try to
collect the information about the legals we have been going through and
solved.
http://cwiki.apache.org/confluence/display/WICKET/Wicket+1.3.0+incubating+checkpoint+1
Frank
On 3/15/07, Igor Vaynberg <[EMAIL PROTECTED]> wrot
we are doing that, but its not a public release
-igor
On 3/14/07, Frank Bille <[EMAIL PROTECTED]> wrote:
+1 and I still think we should do a 1.3 release to IPMC "now"
Frank
On 3/15/07, Al Maw <[EMAIL PROTECTED]> wrote:
>
> There's been a lot of comment and discussion lately about the futur
You may need to fix some imports back if you use contrib modules from
wicket-stuff or elsewhere.
Though most of them start with wicket.contrib, so ignoring them should
be good for most.
Eelco
Hi folks,
As part of our ongoing incubation process at Apache, we're going to be
renaming the core wicket package from "wicket" to "org.apache.wicket"
shortly (not quite sure when yet, but soon).
If you're developing against the subversion wicket-1.x branch, you'll
need to change your import
+1 and I still think we should do a 1.3 release to IPMC "now"
Frank
On 3/15/07, Al Maw <[EMAIL PROTECTED]> wrote:
There's been a lot of comment and discussion lately about the future
direction of Wicket, and the trunk/2.0 branch in particular.
We've done some hard thinking and we now have a
+1 (binding)
-igor
On 3/14/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
+1 (binding)
Eelco
On 3/14/07, Al Maw <[EMAIL PROTECTED]> wrote:
> There's been a lot of comment and discussion lately about the future
> direction of Wicket, and the trunk/2.0 branch in particular.
>
> We've done so
+1 (binding)
Eelco
On 3/14/07, Al Maw <[EMAIL PROTECTED]> wrote:
There's been a lot of comment and discussion lately about the future
direction of Wicket, and the trunk/2.0 branch in particular.
We've done some hard thinking and we now have a roadmap for the future.
When What
+1 (binding)
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org
We've done some hard thinking and we now have a roadmap for the future.
+1
Al
There's been a lot of comment and discussion lately about the future
direction of Wicket, and the trunk/2.0 branch in particular.
We've done some hard thinking and we now have a roadmap for the future.
When What
Now Backport the Model refactor and other rem
Igor Vaynberg wrote:
well yes, but jbq was saying we should create a special page for when this
happens. and i disagreed. and then you disagreed with me, so are you
agreeing with jbq?
I'm agreeing with you.
This stuff is so much easier to do on IRC / IRL. :)
Well, it should probably be l
well yes, but jbq was saying we should create a special page for when this
happens. and i disagreed. and then you disagreed with me, so are you
agreeing with jbq?
-igor
On 3/14/07, Al Maw <[EMAIL PROTECTED]> wrote:
Igor Vaynberg wrote:
> errr, no!
>
> what if iswicketurl does return true? may
Igor Vaynberg wrote:
errr, no!
what if iswicketurl does return true? maybe you do ?bookmarkablePage=
some.FooBarPage
and FooBarPage does not exist. what to do then? we should just set the
header to 404 and let the chain continue
Hmmm. Shouldn't we leave it all alone and just let the request f
errr, no!
what if iswicketurl does return true? maybe you do ?bookmarkablePage=
some.FooBarPage
and FooBarPage does not exist. what to do then? we should just set the
header to 404 and let the chain continue
-igor
On 3/14/07, Al Maw <[EMAIL PROTECTED]> wrote:
Igor Vaynberg wrote:
> erm no
>
Igor Vaynberg wrote:
erm no
the important thing is that what we do is set the 404 header
that way the filter chain knows its a 404 and can handle it properly
as opposed to us happily streaming our own error page with a 200
Errr, no. :-) We don't want to stream anything at all in the filter
erm no
the important thing is that what we do is set the 404 header
that way the filter chain knows its a 404 and can handle it properly
as opposed to us happily streaming our own error page with a 200
-igor
On 3/14/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
exactly
-igor
On 3/14/07,
exactly
-igor
On 3/14/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote:
* Al Maw:
> Err, if you use a filter then you fall through and do whatever
> the container does. Please don't break it for the filter case.
So you say it's not a good idea to throw a PageNotFoundException,
rather
* [EMAIL PROTECTED]:
> Author: knopp
> Date: Wed Mar 14 09:45:14 2007
> New Revision: 518211
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=518211
> Log:
> form serialization fix
>
> Modified:
>
> incubator/wicket/branches/wicket-1.x/jdk-1.4/wicket/src/main/java/wicket/ajax/wicket-ajax.j
* Al Maw:
> Err, if you use a filter then you fall through and do whatever
> the container does. Please don't break it for the filter case.
So you say it's not a good idea to throw a PageNotFoundException,
rather ensure that isWicketRequest() returns false to let the
request flow to the n
Jean-Baptiste Quenot wrote:
* Johan Compagner:
What do we now when a bookmarkable page is asked for but not
found? just the 404? with nothing else?
Currently we log an error and return the error page with status
code 500, that's BAD!
Err, if you use a filter then you fall through and
I'd only opt for one level deep. i.e. direct fields. At least that is
what we do currently.
Martijn
On 3/14/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
but thats slow..you have to traverse the entire object graph of the page no?
and the class graph. yikes.
we should use aspectj load time weav
Sounds neat. Go for it.
Eelco
On 3/14/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote:
(15:01:35) jbq: time for a poll
(15:01:55) jbq: would you like it in wicket core?
(15:02:00) jbq: or anywhere else?
(15:02:04) jbq: (not /dev/null please)
See http://issues.apache.org/jira/browse/WICKET-3
On 3/14/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
because this stuff started out made specifically for spring. later i
generalized it some to make it useful for general injection cases. since we
didnt want to break api too much in 1.3 i only moved the generalized stuff
into extensions in 2.0
We've been here before though. :) It seems impossible to come to a
common understanding on this. For the record, I agree with Johan, but
I think that if we can't agree on whether to call it beta, we should
just call it alpha or integration build or something. As long as we
keep going trying to pus
sure. but it is the magnitude of those changes.
beta should more or less be feature complete. all these changes you are
backporting are features.
-igor
On 3/14/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
beta == changes can happen..
beta != api is stable.
johan
On 3/11/07, Igor Vaynber
Finally found WIFI hotspot!!!
yeahh :)
8 bucks an hour!
ripoff!! :(
johan
On 3/14/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
Johan! No skiing?
Martijn
On 3/14/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> yeah it is it pretty nice utility.
> can go into util.
>
> johan
>
>
> On 3/1
beta == changes can happen..
beta != api is stable.
johan
On 3/11/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
i am afraid of people starting to use it. put a lot of time into it, then
upgrade to beta2 and have to redo a bunch of crap. if this happened to me
id
be pissed, i dont like to have
Johan! No skiing?
Martijn
On 3/14/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
yeah it is it pretty nice utility.
can go into util.
johan
On 3/14/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>
> oi. i see a lot of questions coming in why models arent being detached :)
>
> -igor
>
>
> On 3/
yeah it is it pretty nice utility.
can go into util.
johan
On 3/14/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
oi. i see a lot of questions coming in why models arent being detached :)
-igor
On 3/14/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
>
> I'd only opt for one level deep. i.e.
I see a lot of answers coming: read the javadoc :)
Martijn
On 3/14/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
oi. i see a lot of questions coming in why models arent being detached :)
-igor
On 3/14/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
>
> I'd only opt for one level deep. i.e. di
because this stuff started out made specifically for spring. later i
generalized it some to make it useful for general injection cases. since we
didnt want to break api too much in 1.3 i only moved the generalized stuff
into extensions in 2.0
in 1.3 and in 1.2 it is still in wicket-spring
-igor
So when a bookmarkable page can't be found we throw that error?
We could do that but would that help a lot?
What do we now when a bookmarkable page is asked for but not found?
just the 404? with nothing else?
Maybe we could reusse the accessdenied?
(you are trying to get things that you shouldn't
its an error :)
On 3/14/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote:
* Johan Compagner:
> What do we now when a bookmarkable page is asked for but not
> found? just the 404? with nothing else?
Currently we log an error and return the error page with status
code 500, that's BAD!
DOH! - that was the only part i didnt checkout as i dont use spring... thx
for info, now I will fix the JEE to work... btw: why is it in spring, as the
base InjectionClasses are needed by other extensions (like Filippos JEE) as
well; in 1.2 the necessary part was in wicket-extension box where it IM
* Johan Compagner:
> What do we now when a bookmarkable page is asked for but not
> found? just the 404? with nothing else?
Currently we log an error and return the error page with status
code 500, that's BAD!
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
On 3/14/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
you are an admin in bamboo arent you? :)
Well, yes, but I didn't know if someone was working on it or this was
just a slip.
Eelco
oi. i see a lot of questions coming in why models arent being detached :)
-igor
On 3/14/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
I'd only opt for one level deep. i.e. direct fields. At least that is
what we do currently.
Martijn
On 3/14/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>
im fine with it going into core
-igor
On 3/14/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote:
(15:01:35) jbq: time for a poll
(15:01:55) jbq: would you like it in wicket core?
(15:02:00) jbq: or anywhere else?
(15:02:04) jbq: (not /dev/null please)
See http://issues.apache.org/jira/brows
but thats slow..you have to traverse the entire object graph of the page no?
and the class graph. yikes.
we should use aspectj load time weaver to instrument Component classes to do
this! :) now there is a case of "aop" i can go for.
-igor
On 3/14/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote
and it should be there as well for 1.2
-igor
On 3/14/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
it is in wicket-spring :)
-igor
On 3/14/07, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> as 2.0 future's seems unclear i decided to move to 1.3. Today i got a
> fresh
> 1.3 from the
it is in wicket-spring :)
-igor
On 3/14/07, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
Hi,
as 2.0 future's seems unclear i decided to move to 1.3. Today i got a
fresh
1.3 from the 1.x SVN, build it usig mvn -Dskip.test=true clean install and
after 10 mins i had it :)
However, after setting
you are an admin in bamboo arent you? :)
what we need to decide is how we want those builds. as a single branch or as
individuals projects like in wicket-1.2.x and 2.x
-igor
On 3/13/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
It seems Bamboo isn't updated for the new structure yet, and n
-- Forwarded message --
From: Jukka Zitting <[EMAIL PROTECTED]>
Date: Mar 14, 2007 3:06 PM
Subject: Fwd: Google Summer of Code
To: general@incubator.apache.org
Hi,
Woden and Tuscany have already proposed GSoC projects. Other
incubating projects might also be interested.
Notice
In our project we have things that use IModel fields. I have created a
utility class that uses reflection to find all IDetachable fields in
an object and calls detach() on them. Is this something for
wicket.util?
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket c
Currently we have:
* AccessDeniedPage
* ExceptionErrorPage
* InternalErrorPage
* PageExpiredErrorPage
But we don't have a page to report an URL that does not point to
an existing resource. What about adding that?
For example it would be needed here:
PackageRequestTargetUrlCodingStrategy should
(15:01:35) jbq: time for a poll
(15:01:55) jbq: would you like it in wicket core?
(15:02:00) jbq: or anywhere else?
(15:02:04) jbq: (not /dev/null please)
See http://issues.apache.org/jira/browse/WICKET-357
Thanks in advance for your comments.
--
Jean-Baptiste Quenot
aka John Banana Qwer
Hmm, the link doesn't work and if it only sends on failure, can't we
send it to @dev?
Martijn
On 3/14/07, Default <[EMAIL PROTECTED]> wrote:
This is an initial or manual build of the Wicket-1.x - JDK-1.4 Root Module
build.
--
49 matches
Mail list logo
