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

Reply via email to