[
https://issues.apache.org/jira/browse/WICKET-6459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16152858#comment-16152858
]
ASF GitHub Bot commented on WICKET-6459:
----------------------------------------
Github user martin-g commented on a diff in the pull request:
https://github.com/apache/wicket/pull/232#discussion_r136861843
--- Diff:
wicket-core/src/test/java/org/apache/wicket/markup/renderStrategy/ChildFirstHeaderRenderStrategyTest.java
---
@@ -51,6 +57,39 @@ public void test2() throws Exception
}
/**
+ * Tests that when a controller of an enclosure is added to the ajax
target, its header
+ * contributions reach the response
+ *
+ * WICKET-6459
+ *
+ */
+ @Test
+ public void testAjaxAndEnclosures() throws Exception
+ {
+
+ tester.startPage(SimplePage3.class);
--- End diff --
Let's rename the page name to `InlineEnclosureAjaxRenderPage`.
`SimplePage`s are legacy, but for new stuff we should try better! :-)
> Ajax re-renders of enclosures do not render their children's header
> contributions
> ---------------------------------------------------------------------------------
>
> Key: WICKET-6459
> URL: https://issues.apache.org/jira/browse/WICKET-6459
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 8.0.0-M6, 7.8.0
> Reporter: Domas Poliakas
> Priority: Minor
>
> When a component in an enclosure is added to the AjaxRequestTarget, its (and
> subsequently its children's) header contributions are not rendered.
> AjaxEnclosureListener replaces any components with enclosures that are in the
> target with their enclosures. However, in the wicket hierarchy the enclosures
> appear to be siblings to the components they enclose. What this causes is
> that when the default ChildFirstHeaderRenderStrategy attempts to render the
> header contributions for the enclosure, nothing is rendered as the enclosure
> itself has no children in the hierarchy.
> On one hand, ChildFirstHeaderRenderStrategy seems to be the culprit - it
> should detect enclosures and act accordingly - but fixing the problem there
> would cause it to resurface in the future if the default implementation of
> header render strategy is changed. What would be a correct way fix for this?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
