Hey it's the man himself. :) We already use the automatic AJAX feedback recipe (thanks for that), but I'm not sure how that solves the problem at hand. I only add the temporary behaviors in myIComponentOnBeforeRenderListener, and that only gets called if the component's *already* been added to the ART. If the behavior weren't temporary then your suggestion makes sense, assuming we're okay with visiting the entire page for every AJAX request. But once we've paid that cost, why not just add the temporary behavior during visitation?
I suppose I don't mind scouring the component graph for invalid FormComponents if and only if !Session.getFeedbackMessages().isEmpty(). Do you agree with this approach, or am I missing your point? Regards, Dan On Wed, Jul 20, 2011 at 8:15 PM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote: > no worries, the cookbook has your back! > > look in this recipe: Providing Ajax feedback automatically > > have your temporary behavior implement a tagging interface. then in > the ajax request target listener look for all components that have a > behavior with this tagging interface, and if they do add it to the > target. > > -igor > > > On Wed, Jul 20, 2011 at 8:01 PM, Dan Retzlaff <dretzl...@gmail.com> wrote: > > Hey all, > > > > I want a low-interference approach to adding CSS class attributes to form > > components and their labels when they have associated errors. Igor's * > > Cookbook* suggests a behavior, but leaves the automation as something > done > > during page construction. We have too many AJAX modals and panel updates > for > > this to cover everything. Therefore I wrote > > an IComponentOnBeforeRenderListener that adds temporary behaviors to > > FormComponents and FormComponentLabels which has me pretty close to > nirvana. > > However, the problem remains of getting the form components (or at least > the > > form) added to AjaxRequestTargets. It seems like I want an > application-level > > form submit listener, but I'm not sure how to approach that. > > > > Any suggestions or criticisms? This would be awesome for us to get > working. > > > > Dan > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
