You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Eelco Hillenius (JIRA)" <ji...@apache.org> on 2007/08/24 01:30:30 UTC

[jira] Commented: (WICKET-882) RefreshingView should call super.onBeforeRender after it refreshed it's items.

    [ https://issues.apache.org/jira/browse/WICKET-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522311 ] 

Eelco Hillenius commented on WICKET-882:
----------------------------------------

Same thing goes for SelectOptions, Loop and possibly AjaxEditableLabel and ModalWindow. It is probably the safer default anyway.

> RefreshingView should call super.onBeforeRender after it refreshed it's items.
> ------------------------------------------------------------------------------
>
>                 Key: WICKET-882
>                 URL: https://issues.apache.org/jira/browse/WICKET-882
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.3.0-beta2
>            Reporter: Eelco Hillenius
>             Fix For: 1.3.0-beta3
>
>
> RefreshingView should call super.onBeforeRender after it refreshed it's items.
> Right now, it first visits all it's children, even if those children will be removed right after the call, and it misses any children that got added directly.
> I found out about this because of the recent change where beforeRender calls isVisible, and I had a component in a RefreshingView that had an implementation of isVisible that depended on it's model value, and another component that removes an item in the datamodel that backs the RefreshingView. When an item was removed, beforeRender was still executed on the child with the now stale reference to the data model, resulting in an exception 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.