When an transparent resolved component is rendered, it is able to correctly resolve any wicket:id in the inner html object because it delegates the Component#get to its parent, and it is able to know who are its children components traversing the html at at the markupStream object. So this special component is designed to be aware of children components only at the rendering time ( working with the markupStream ) and not at the pre-rendering. As the ListView depends on pre-rendering logic, add an transparent resolved component in ajax request target has no effect because no children pre-rendering method will be invoked.
On Sun, Nov 28, 2010 at 11:04 AM, Wilhelmsen Tor Iver <[email protected]>wrote: > In my quest for a more portlet-oriented use of Wicket, I am trying an > approach where you switch panels (by constructing new instances and > repainting a "wrapper") within one Page. However, it seems that ListViews do > not get repainted (no calls to populateItem()) in that scenario: > > 1) Initial rendering that does not use Ajax works fine. > 2) An AjaxFallbackButton then switches to a second panel > 3) Returning via an AjaxFallbackLink to a new instance of the first > panel paints all components except the ListView items. > > Is there something I have forgotten? Would it make more sense to have all > Panels in the Page at once and then just adjust visibility as needed? > > A quickstart can be found at > http://dl.dropbox.com/u/11463405/listviewtest.zip > > Med vennlig hilsen > > TOR IVER WILHELMSEN > Senior systemutvikler > Arrive AS > T (+47) 48 16 06 18 > E-post: [email protected] > http://www.arrive.no > http://servicedesk.arrive.no > > > > -- Pedro Henrique Oliveira dos Santos
