Re: Fixing ComponentTest in Wicket 1.x
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 [EMAIL PROTECTED] 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
* 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
wonder if this is a sideffect of wicket-tester? -igor On 1/14/07, Johan Compagner [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
gah!!! 0 failures in eclipse windows 0 failures in cli windows 5 failures in unix wtf -igor On 1/15/07, Igor Vaynberg [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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/
