You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Maeder Thomas <th...@ecofin.ch> on 2007/11/13 16:54:19 UTC
isEnabledInHierarchy?
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?
Posted by Maeder Thomas <th...@ecofin.ch>.
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:e.vanoosten@grons.nl]
> 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?
Posted by Erik van Oosten <e....@grons.nl>.
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?
Posted by Maeder Thomas <th...@ecofin.ch>.
That's the idea.
> -----Original Message-----
> From: Johan Compagner [mailto:jcompagner@gmail.com]
> 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
> <th...@ecofin.ch> 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?
Posted by Maurice Marrink <ma...@gmail.com>.
> 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?
Posted by Maeder Thomas <th...@ecofin.ch>.
> -----Original Message-----
> From: Maurice Marrink [mailto:marrink@gmail.com]
> 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?
Posted by Maurice Marrink <ma...@gmail.com>.
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 <jc...@gmail.com> 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 <th...@ecofin.ch> 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?
Posted by Johan Compagner <jc...@gmail.com>.
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 <th...@ecofin.ch> 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
>