What do you mean? What would the visitor look for? On Tue, Aug 24, 2010 at 1:12 PM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote: > you can accomplish it using a simple visitor. 1.5 has a more > formalized approach for managing events between components. > > -igor > > On Tue, Aug 24, 2010 at 10:07 AM, James Carman > <ja...@carmanconsulting.com> wrote: >> Yes, but how do you make sure all the components that need to be >> updated via ajax are updated? They can point to the same model, but >> if they're not added to the AjaxRequestTarget, then they won't be >> updated when their values change. You'd need some sort of event >> listener I would think (unless you want to pass around references to >> the components that need updating). >> >> On Tue, Aug 24, 2010 at 12:56 PM, Igor Vaynberg <igor.vaynb...@gmail.com> >> wrote: >>> usually this kind of linkage is created by pointing both the calendar >>> and the textfield to the same model object, like a property of a >>> common parent, etc. >>> >>> -igor >>> >>> On Tue, Aug 24, 2010 at 8:37 AM, Patrick Petermair >>> <patrick.peterm...@openforce.com> wrote: >>>> Hi! >>>> >>>> Let's say I have a page with 2 panels. CalendarPanel shows a simple >>>> calendar, FormPanel a basic form. Whenever the user clicks on a date in the >>>> calendar, the textfield of the form should show the selected date. >>>> >>>> What is the best practice for this kind of interaction? >>>> Right now we hold a reference to the FormPanel in CalendarPanel and attach >>>> our custom CalendarAjaxBehavior to it. Whenever the CalendarAjaxBehavior >>>> gets a request / click, it updates the FormPanel's model directly. >>>> >>>> I don't really know if this is some ugly hack or if there is a better way >>>> of >>>> different panels to update / communicate with each other - other than >>>> holding references to one another... >>>> >>>> Cheers, >>>> Patrick >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
