RE: isEnabledInHierarchy?
> -Original Message- > From: Maurice Marrink [mailto:[EMAIL PROTECTED] > Sent: Donnerstag, 15. November 2007 01:30 > To: dev@wicket.apache.org > Subject: Re: isEnabledInHierarchy? > > Sounds logical. And i think you can do it yourself by > checking the isEnabled and isEnableAllowed flags in > onBeforeRender of MarkupContainers and then use a visitor to > update all childs. No, that doesn't work if anything under the root is updated via AJAX. What I could do is attach a behaviour to all children which changes the enabled flag at render time, but that will not work with versioning (checkHierarchyChange). > Only problem i see is that changes made after the container > has done this are not detected but the same is true (i think) > if wicket were to do this in the render phase. > > Maurice It would too work with later changes, what I'm proposing is not changing the enabled flags, but rendering a component based on enabled state from the parent chain instead of just the component itself. Of course, the component in question would always render as disabled as long as an ancestor is disabled, but you don't lose any state changes. I do understand that there are workarounds for this (and I'm implementing one myself right now). The question is: would this be a good idea for wicket itself or am I missing something here? cheers Thomas
Re: isEnabledInHierarchy?
> I do understand that there are workarounds for this (and I'm > implementing one myself right now). The question is: would this be a > good idea for wicket itself or am I missing something here? Nope, an isEnabledInHierarchy sound like a good idea to me. I'm just a little worried what this will do to performance. It's one thing to call isEanbled for every (visible?) component but It's a whole other order of magnitude to call isEnabledInHierarchy for every component which in turn calls isEnabledInHierarchy on every parent, etc etc. Especially because isEnabledInHierarchy will have to check isEnabled and isEnableAllowed on the component itself. With isEnabled being mostly a boolean return that is not the biggest problem but isEnableAllowed goes directly into the security framework which can do pretty much everything even db lookups or file reads if they want to. Caching these results for the duration of the request might be a solution but could also open up a whole other can of worms. Maurice
RE: isEnabledInHierarchy?
That's the idea. > -Original Message- > From: Johan Compagner [mailto:[EMAIL PROTECTED] > Sent: Donnerstag, 15. November 2007 00:07 > To: dev@wicket.apache.org > Subject: Re: isEnabledInHierarchy? > > so if i disable a form then all textfields should be renderd > with disabled=disabled in there tag? > > johan > > > > On Nov 13, 2007 4:54 PM, Maeder Thomas > <[EMAIL PROTECTED]> 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 > > > >
Re: isEnabledInHierarchy?
Sounds logical. And i think you can do it yourself by checking the isEnabled and isEnableAllowed flags in onBeforeRender of MarkupContainers and then use a visitor to update all childs. Only problem i see is that changes made after the container has done this are not detected but the same is true (i think) if wicket were to do this in the render phase. Maurice On Nov 15, 2007 12:06 AM, Johan Compagner <[EMAIL PROTECTED]> wrote: > so if i disable a form then all textfields should be renderd with > disabled=disabled in there tag? > > johan > > > > > On Nov 13, 2007 4:54 PM, Maeder Thomas <[EMAIL PROTECTED]> 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 > > >
Re: isEnabledInHierarchy?
so if i disable a form then all textfields should be renderd with disabled=disabled in there tag? johan On Nov 13, 2007 4:54 PM, Maeder Thomas <[EMAIL PROTECTED]> 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 >
RE: isEnabledInHierarchy?
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: dev@wicket.apache.org > 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/ > >
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/