Hi Martin,
I seen these doubled renderings too, but didn't bother about it - until
recently with a new component that changes on each render :(.
We could add a new method #remove() to ART, but I'd be fine with 1) too.
Note that there might be other components *inside* the enclosure too,
that might be rendered twice if they were added to the ART already :(.
Sven
On 08/05/2013 11:36 AM, Martin Grigorov wrote:
Hi,
We found that using InlineEnclosure doesn't remove the controlling
component from the map with components to be re-rendered.
org.apache.wicket.protocol.http.AjaxEnclosureListener#onBeforeRespond adds
the InlineEnclosure to the ajax target and this leads to Ajax response like:
<?xml version="1.0" encoding="UTF-8"?>
<ajax-response>
<component id="cc7" ><![CDATA[<div wicket:id="cc" id="cc7">New
CC</div>]]></component>
<component id="wicket__InlineEnclosure_06" ><![CDATA[<div
wicket:enclosure="cc" id="wicket__InlineEnclosure_06">
Before<br/>
<div wicket:id="cc" id="cc7">New CC</div>
After<br/>
</div>]]>
</component>
</ajax-response>
I.e. the controlling component (cc7) is rendered twice in the server and
replaced twice in the browser.
At org.apache.wicket.ajax.XmlAjaxResponse#fireOnBeforeRespondListeners
Wicket passes an unmodifiable map to all registered listeners and thus a
listener cannot remove entries from the map.
Later org.apache.wicket.ajax.AbstractAjaxResponse#writeComponents() removes
any component which has a parent also added for repainting but as you may
know Enclosures are not visible in the hierarchy and the filtering doesn't
work in this case.
At the moment I see two solutions:
1) pass the original and modifiable map to the listeners so they can
manipulate it
2) move the code
of org.apache.wicket.protocol.http.AjaxEnclosureListener#onBeforeRespond
inside AjaxRequestHandler and work with the modifiable map
I like the first one better but the listeners were working with
non-modifiable map since their day one.
Do you have better solutions ?
https://issues.apache.org/jira/browse/WICKET-5302
