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/
>


Reply via email to