You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jean-Baptiste Quenot <jb...@apache.org> on 2007/01/13 15:31:36 UTC
Fixing ComponentTest in Wicket 1.x
Hi,
I'm trying to fix the last test failure in branch 1.x but I need
help. Here is the failure:
-------------------------------------------------------------------------------
Test set: wicket.ComponentTest
-------------------------------------------------------------------------------
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.089 sec <<< FAILURE!
testDetachPageAjaxRequest(wicket.ComponentTest) Time elapsed: 0.046 sec <<< FAILURE!
junit.framework.AssertionFailedError: expected:<2> but was:<3>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at junit.framework.Assert.assertEquals(Assert.java:207)
at wicket.ComponentTest.testDetachPageAjaxRequest(ComponentTest.java:92)
Apparently the component is detached 2 times: one time by
BehaviorRequestTarget, and one time by AjaxRequestTarget.
What is the expected process when a behavior is executed via AJAX?
Can you explain a little bit?
Oh and BTW once this test is fixed, IncrementalTableNavigationTest
will need to be updated. They are tied together as the number of
detachs has an impact on the generated behavior URLs apparently.
All the best,
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Fixing ComponentTest in Wicket 1.x
Posted by Johan Compagner <jc...@gmail.com>.
but when to execute that thing?
And what would be the big change? Instead of now RequestCycle.detach()
calling detach() on the RequestTargets
(that are the pages that are used in the current request) What would be
called now and when?
We first need to move the Session.touch(page) command to a much later time
(after the detach) Because Session.touch() pushes the page to the pagemap
and then the httpsession/sessionstore
And then the page already needs to be detached.
johan
On 1/18/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
>
> * Martijn Dashorst:
>
> > I'd rather see an extra step in our request processing that
> > detaches all pages and their child components that have
> > participated in the request processing, instead of relying on
> > the request targets to do so.
>
> +1
> --
> Jean-Baptiste Quenot
> aka John Banana Qwerty
> http://caraldi.com/jbq/
>
Re: Fixing ComponentTest in Wicket 1.x
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Martijn Dashorst:
> I'd rather see an extra step in our request processing that
> detaches all pages and their child components that have
> participated in the request processing, instead of relying on
> the request targets to do so.
+1
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Fixing ComponentTest in Wicket 1.x
Posted by Martijn Dashorst <ma...@gmail.com>.
The problem with this assumption is that the components get attached.
This is not (necessarily) so. Models get attached, but don't
participate in the request cycle.
MyPage(Person p) {
setModel(new CompoundPropertyModel(new LoadableDetachableModel(p)));
add(new Label("name").add(new
AjaxSelfUpdatingBehavior(Duration.seconds(1)));
}
This behavior will only touch the label, but attach the model of the
page, if I'm not mistaken.
I'd rather see an extra step in our request processing that detaches
all pages and their child components that have participated in the
request processing, instead of relying on the request targets to do
so.
Martijn
On 1/16/07, Igor Vaynberg <ig...@gmail.com> wrote:
> seems like we really cant fix this.
>
> what is happening is this:
>
> the behavior url is rqeuested
> behaviortarget is resolved and pushed onto the request cycle
> behaviortarget pushes ajaxrequesttarget onto the request cycle
>
> request is processed
>
> request cycle cleans up by calling deatch() on all pushed request targets
>
> ajaxrequsttarget detaches the page
> behaviortarget detaches the page
>
> thus two detaches
>
> if we truelly want request targets to be independent this is how they have
> to work if they make no assumptions
>
> we have a multiple attach/detach guard on the page itself, but that doesnt
> work because ajaxrequesttarget only attaches components it needs, so the
> page is never marked as attached
>
> (a) a solution i see is to do something similar we did in 2.0 where we force
> super() call in internalattach/internaldetach and use flags to only
> attach/detach components that have been attached.
>
> (b) have a page.markattached() method - but this is ugly
>
> (c) ignore the problem and allow detach() to be called more then once in 1.x
>
> i think if we had a vote i would go vote for (a)
>
> -igor
>
>
> On 1/13/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
> >
> > Hi,
> >
> > I'm trying to fix the last test failure in branch 1.x but I need
> > help. Here is the failure:
> >
> >
> > -------------------------------------------------------------------------------
> > Test set: wicket.ComponentTest
> >
> > -------------------------------------------------------------------------------
> > Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.089 sec
> > <<< FAILURE!
> > testDetachPageAjaxRequest(wicket.ComponentTest) Time elapsed: 0.046sec <<< FAILURE!
> > junit.framework.AssertionFailedError: expected:<2> but was:<3>
> > at junit.framework.Assert.fail(Assert.java:47)
> > at junit.framework.Assert.failNotEquals(Assert.java:282)
> > at junit.framework.Assert.assertEquals(Assert.java:64)
> > at junit.framework.Assert.assertEquals(Assert.java:201)
> > at junit.framework.Assert.assertEquals(Assert.java:207)
> > at wicket.ComponentTest.testDetachPageAjaxRequest(
> > ComponentTest.java:92)
> >
> > Apparently the component is detached 2 times: one time by
> > BehaviorRequestTarget, and one time by AjaxRequestTarget.
> >
> > What is the expected process when a behavior is executed via AJAX?
> > Can you explain a little bit?
> >
> > Oh and BTW once this test is fixed, IncrementalTableNavigationTest
> > will need to be updated. They are tied together as the number of
> > detachs has an impact on the generated behavior URLs apparently.
> >
> > All the best,
> > --
> > Jean-Baptiste Quenot
> > aka John Banana Qwerty
> > http://caraldi.com/jbq/
> >
>
>
--
Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket
Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now!
http://wicketframework.org
Re: Fixing ComponentTest in Wicket 1.x
Posted by Johan Compagner <jc...@gmail.com>.
Maybe something like this: (quick 'pseudo' code)
final MarkupContainer.internalDetach()
{
super.internalDetach();
for each childere()
{
child.internalDetach();
child.hasOnDetachBeCalled(); // throws an excepton when
component.onDetach() is not reached.
}
}
Component.internalDetach() (can't be final because container has to be able
to override it)
{
if(attached)
{
attached = false;
onDetach()
}
}
Component.onDetach()
{
// set the flag that onDetach is called...
model.onDetach()
behaviours.onDetach()
}
Component.onAttach()
{
attached = true;
}
Then maybe win attach we do the same..
johan
On 1/16/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> seems like we really cant fix this.
>
> what is happening is this:
>
> the behavior url is rqeuested
> behaviortarget is resolved and pushed onto the request cycle
> behaviortarget pushes ajaxrequesttarget onto the request cycle
>
> request is processed
>
> request cycle cleans up by calling deatch() on all pushed request targets
>
> ajaxrequsttarget detaches the page
> behaviortarget detaches the page
>
> thus two detaches
>
> if we truelly want request targets to be independent this is how they have
> to work if they make no assumptions
>
> we have a multiple attach/detach guard on the page itself, but that doesnt
> work because ajaxrequesttarget only attaches components it needs, so the
> page is never marked as attached
>
> (a) a solution i see is to do something similar we did in 2.0 where we
> force
> super() call in internalattach/internaldetach and use flags to only
> attach/detach components that have been attached.
>
> (b) have a page.markattached() method - but this is ugly
>
> (c) ignore the problem and allow detach() to be called more then once in
> 1.x
>
> i think if we had a vote i would go vote for (a)
>
> -igor
>
>
> On 1/13/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
> >
> > Hi,
> >
> > I'm trying to fix the last test failure in branch 1.x but I need
> > help. Here is the failure:
> >
> >
> >
> -------------------------------------------------------------------------------
> > Test set: wicket.ComponentTest
> >
> >
> -------------------------------------------------------------------------------
> > Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.089sec
> > <<< FAILURE!
> > testDetachPageAjaxRequest(wicket.ComponentTest) Time elapsed: 0.046sec <<<
> FAILURE!
> > junit.framework.AssertionFailedError: expected:<2> but was:<3>
> > at junit.framework.Assert.fail(Assert.java:47)
> > at junit.framework.Assert.failNotEquals(Assert.java:282)
> > at junit.framework.Assert.assertEquals(Assert.java:64)
> > at junit.framework.Assert.assertEquals(Assert.java:201)
> > at junit.framework.Assert.assertEquals(Assert.java:207)
> > at wicket.ComponentTest.testDetachPageAjaxRequest(
> > ComponentTest.java:92)
> >
> > Apparently the component is detached 2 times: one time by
> > BehaviorRequestTarget, and one time by AjaxRequestTarget.
> >
> > What is the expected process when a behavior is executed via AJAX?
> > Can you explain a little bit?
> >
> > Oh and BTW once this test is fixed, IncrementalTableNavigationTest
> > will need to be updated. They are tied together as the number of
> > detachs has an impact on the generated behavior URLs apparently.
> >
> > All the best,
> > --
> > Jean-Baptiste Quenot
> > aka John Banana Qwerty
> > http://caraldi.com/jbq/
> >
>
>
Re: Fixing ComponentTest in Wicket 1.x
Posted by Igor Vaynberg <ig...@gmail.com>.
gah!!!
0 failures in eclipse windows
0 failures in cli windows
5 failures in unix
wtf
-igor
On 1/15/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> seems like we really cant fix this.
>
> what is happening is this:
>
> the behavior url is rqeuested
> behaviortarget is resolved and pushed onto the request cycle
> behaviortarget pushes ajaxrequesttarget onto the request cycle
>
> request is processed
>
> request cycle cleans up by calling deatch() on all pushed request targets
>
> ajaxrequsttarget detaches the page
> behaviortarget detaches the page
>
> thus two detaches
>
> if we truelly want request targets to be independent this is how they have
> to work if they make no assumptions
>
> we have a multiple attach/detach guard on the page itself, but that doesnt
> work because ajaxrequesttarget only attaches components it needs, so the
> page is never marked as attached
>
> (a) a solution i see is to do something similar we did in 2.0 where we
> force super() call in internalattach/internaldetach and use flags to only
> attach/detach components that have been attached.
>
> (b) have a page.markattached() method - but this is ugly
>
> (c) ignore the problem and allow detach() to be called more then once in
> 1.x
>
> i think if we had a vote i would go vote for (a)
>
> -igor
>
>
> On 1/13/07, Jean-Baptiste Quenot <jbq@apache.org > wrote:
> >
> > Hi,
> >
> > I'm trying to fix the last test failure in branch 1.x but I need
> > help. Here is the failure:
> >
> >
> > -------------------------------------------------------------------------------
> > Test set: wicket.ComponentTest
> > -------------------------------------------------------------------------------
> >
> > Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.089sec <<< FAILURE!
> > testDetachPageAjaxRequest(wicket.ComponentTest) Time elapsed: 0.046sec <<< FAILURE!
> > junit.framework.AssertionFailedError : expected:<2> but was:<3>
> > at junit.framework.Assert.fail(Assert.java:47)
> > at junit.framework.Assert.failNotEquals(Assert.java:282)
> > at junit.framework.Assert.assertEquals(Assert.java :64)
> > at junit.framework.Assert.assertEquals(Assert.java:201)
> > at junit.framework.Assert.assertEquals(Assert.java:207)
> > at wicket.ComponentTest.testDetachPageAjaxRequest(
> > ComponentTest.java:92)
> >
> > Apparently the component is detached 2 times: one time by
> > BehaviorRequestTarget, and one time by AjaxRequestTarget.
> >
> > What is the expected process when a behavior is executed via AJAX?
> > Can you explain a little bit?
> >
> > Oh and BTW once this test is fixed, IncrementalTableNavigationTest
> > will need to be updated. They are tied together as the number of
> > detachs has an impact on the generated behavior URLs apparently.
> >
> > All the best,
> > --
> > Jean-Baptiste Quenot
> > aka John Banana Qwerty
> > http://caraldi.com/jbq/
> >
>
>
Re: Fixing ComponentTest in Wicket 1.x
Posted by Igor Vaynberg <ig...@gmail.com>.
seems like we really cant fix this.
what is happening is this:
the behavior url is rqeuested
behaviortarget is resolved and pushed onto the request cycle
behaviortarget pushes ajaxrequesttarget onto the request cycle
request is processed
request cycle cleans up by calling deatch() on all pushed request targets
ajaxrequsttarget detaches the page
behaviortarget detaches the page
thus two detaches
if we truelly want request targets to be independent this is how they have
to work if they make no assumptions
we have a multiple attach/detach guard on the page itself, but that doesnt
work because ajaxrequesttarget only attaches components it needs, so the
page is never marked as attached
(a) a solution i see is to do something similar we did in 2.0 where we force
super() call in internalattach/internaldetach and use flags to only
attach/detach components that have been attached.
(b) have a page.markattached() method - but this is ugly
(c) ignore the problem and allow detach() to be called more then once in 1.x
i think if we had a vote i would go vote for (a)
-igor
On 1/13/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
>
> Hi,
>
> I'm trying to fix the last test failure in branch 1.x but I need
> help. Here is the failure:
>
>
> -------------------------------------------------------------------------------
> Test set: wicket.ComponentTest
>
> -------------------------------------------------------------------------------
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.089 sec
> <<< FAILURE!
> testDetachPageAjaxRequest(wicket.ComponentTest) Time elapsed: 0.046sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<2> but was:<3>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:282)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:201)
> at junit.framework.Assert.assertEquals(Assert.java:207)
> at wicket.ComponentTest.testDetachPageAjaxRequest(
> ComponentTest.java:92)
>
> Apparently the component is detached 2 times: one time by
> BehaviorRequestTarget, and one time by AjaxRequestTarget.
>
> What is the expected process when a behavior is executed via AJAX?
> Can you explain a little bit?
>
> Oh and BTW once this test is fixed, IncrementalTableNavigationTest
> will need to be updated. They are tied together as the number of
> detachs has an impact on the generated behavior URLs apparently.
>
> All the best,
> --
> Jean-Baptiste Quenot
> aka John Banana Qwerty
> http://caraldi.com/jbq/
>
Re: Fixing ComponentTest in Wicket 1.x
Posted by Frank Bille <fr...@gmail.com>.
On 1/13/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
>
> I'm trying to fix the last test failure in branch 1.x
~jbq++
:o)
Re: Fixing ComponentTest in Wicket 1.x
Posted by Igor Vaynberg <ig...@gmail.com>.
wonder if this is a sideffect of wicket-tester?
-igor
On 1/14/07, Johan Compagner <jc...@gmail.com> wrote:
>
> But that can then only be happening if the detach is called between
> rendering calls of specific components
> (so in one request)
>
> Then page get's detached (makes the version final) and then it renders
> again
> one or more component
> that again makes a new version all in the same request..
> thats really bad..
>
> johan
>
>
> On 1/14/07, Martijn Dashorst <ma...@gmail.com> wrote:
> >
> > Apparently the version number is upped by one. I saw this myself when
> > I did my first go at the problem...
> >
> > Martijn
> >
> > On 1/14/07, Johan Compagner <jc...@gmail.com> wrote:
> > > >
> > > > Oh and BTW once this test is fixed, IncrementalTableNavigationTest
> > > > will need to be updated. They are tied together as the number of
> > > > detachs has an impact on the generated behavior URLs apparently.
> > >
> > >
> > >
> > > really?
> > > detach is called after everything is generated. So how is the output
> > > different
> > > thats strange.
> > >
> > > johan
> > >
> > >
> >
> >
> > --
> > Vote for Wicket at the
> > http://www.thebeststuffintheworld.com/vote_for/wicket
> > Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now!
> > http://wicketframework.org
> >
>
>
Re: Fixing ComponentTest in Wicket 1.x
Posted by Johan Compagner <jc...@gmail.com>.
But that can then only be happening if the detach is called between
rendering calls of specific components
(so in one request)
Then page get's detached (makes the version final) and then it renders again
one or more component
that again makes a new version all in the same request..
thats really bad..
johan
On 1/14/07, Martijn Dashorst <ma...@gmail.com> wrote:
>
> Apparently the version number is upped by one. I saw this myself when
> I did my first go at the problem...
>
> Martijn
>
> On 1/14/07, Johan Compagner <jc...@gmail.com> wrote:
> > >
> > > Oh and BTW once this test is fixed, IncrementalTableNavigationTest
> > > will need to be updated. They are tied together as the number of
> > > detachs has an impact on the generated behavior URLs apparently.
> >
> >
> >
> > really?
> > detach is called after everything is generated. So how is the output
> > different
> > thats strange.
> >
> > johan
> >
> >
>
>
> --
> Vote for Wicket at the
> http://www.thebeststuffintheworld.com/vote_for/wicket
> Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now!
> http://wicketframework.org
>
Re: Fixing ComponentTest in Wicket 1.x
Posted by Martijn Dashorst <ma...@gmail.com>.
Apparently the version number is upped by one. I saw this myself when
I did my first go at the problem...
Martijn
On 1/14/07, Johan Compagner <jc...@gmail.com> wrote:
> >
> > Oh and BTW once this test is fixed, IncrementalTableNavigationTest
> > will need to be updated. They are tied together as the number of
> > detachs has an impact on the generated behavior URLs apparently.
>
>
>
> really?
> detach is called after everything is generated. So how is the output
> different
> thats strange.
>
> johan
>
>
--
Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket
Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now!
http://wicketframework.org
Re: Fixing ComponentTest in Wicket 1.x
Posted by Johan Compagner <jc...@gmail.com>.
>
> Oh and BTW once this test is fixed, IncrementalTableNavigationTest
> will need to be updated. They are tied together as the number of
> detachs has an impact on the generated behavior URLs apparently.
really?
detach is called after everything is generated. So how is the output
different
thats strange.
johan