That only works when you can actively intercept the change from enabled to disabled (unless you do it in the rendering cycle as outlined below). That is not really an option in our case. And anyway, any changes in enablement which might occur below the root will be lost when restoring the previous enablement state.
No, I remain convinced that only the framework itself can properly solve the problem. What I was hoping for was some reaction from the commiter crowd. Is it more "yeah, cool idea, we'll do it ASAP after 1.3" or more "shut up noob, that's a dumb idea and here's why". I would certainly try to avoid that kind of pattern in the future if no solution is in sight. And I genuinely think it would improve Wicket. Would a patch help? Thomas > -----Original Message----- > From: Erik van Oosten [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 13. November 2007 20:58 > To: [email protected] > Subject: Re: isEnabledInHierarchy? > > Not a permanent solution, but its quite easy to use a > IVisitor to visit all nodes recursively. > > Regards, > Erik. > > > Maeder Thomas wrote: > > Hi folks, > > > > we're currently struggling with the case of a complex > component tree > > (nested AJAX tabbed panels) which we would like to > enable/disable in > > one go (i.e. disable every component below a given root). > I've tried > > the approach where I call setEnabled(false) on every child > of the root > > in onBeforeRender(), but this doesn't work, since we have AJAX > > elements below the root. > > > > I've found a conversation in the old wicket lists where > somebody was > > asking why enablement was not determined recursively like > visibility. > > I.e. a component is rendered as disabled if the > enabled-flag is set on > > the component or if the component's parent is disabled. > However, the > > thread just ended without any resolution. > > I currently see no way to implement our desired behaviour short of > > touching every input component in our component tree. On the other > > hand, I see no reason why wicket should not determine > enablement recursively. > > > > thoughts? > > > > Thomas > > > > -- > Erik van Oosten > http://2008.rubyenrails.nl/ > http://day-to-day-stuff.blogspot.com/ > >
