Hello, I decided to take another look at this problem and noticed that AJAX-based refreshing of a page with a DataView changes the path of the DataView's first element. For example, when the page is first rendered, the path of the first row in the DataView is "referrals:1". After the DataView is refreshed using AJAX the path of the first row changes to "referrals:2". The path continues to change as DataView is refreshed over and over again.
This is the reason why in my original post verification in step 2 (before ajax refresh) passes and the same verification in step 4 (after ajax refresh) fails. I can fix step 4 by verifying the step of "referrals:2" element. The fragility of wicket path seems to be a known problem and some people recommended using a visitor to verify the state of component's children instead of relying on the wicket path. Any other options I should consider for this? Thanks On Wed, Sep 22, 2010 at 10:43 AM, Alec Swan <alecs...@gmail.com> wrote: > Well, the table gets correctly refreshed through an AJAX event, it's just > that WicketTester can't find any rows in the table after that. > > Is this a known WicketTester bug? > > > On Wed, Sep 22, 2010 at 12:41 AM, Wilhelmsen Tor Iver > <toriv...@arrive.no>wrote: > >> > I remember reading somewhere that using AJAX to refresh a component >> > generated using "repeater" may cause some problems. Is this what I am >> > against here with WicketTester? (Keep in mind that the table does get >> > refreshed correctly in production.) >> >> Repeaters are special in the sense that they take their markup and >> repeatedly use it, thus there is not one "repeater" element in the DOM. To >> use a repeater with Ajax you need to wrap it in e.g. a WebMarkupContainer >> and then repaint that with Ajax. >> >> - Tor Iver >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >
