isEnabled() controls whether the behavior is enabled or not and not the component.
-igor On Fri, Jul 1, 2011 at 2:53 PM, Christian Huber <[email protected]> wrote: > Hi again. > > Igor, thanks for your clarification, after changing isEnabled to return true > the other callbacks do indeed get called. > > But to be honest I am still a bit confused by this fact and would be > grateful for further information. The javadoc of isEnabled says that it is > called when a component _is_ rendering which gave me the impression that > isEnabled should be called _after_ onConfigure and beforeRender. > > Furthermore a component can be disabled but is still rendered (like a > disabled checkbox) which in my opinion should still cause the rendering > callbacks to be invoked. To my understanding that is not the case. > > And last but not least, even though the behavior did return false in > isEnabled the links it was attached to where fully functional which a > disabled component should not be as far as I know. > > All this leads me to the believe that my understanding of an enabled > component in wicket terms s not correct. Any pointers would be greatly > appreciated. > > Cheers, > Chris > > Am 30.06.2011 22:20, schrieb Christian Huber: >> >> I just created a quick start with 1.4.17 where I added my behavior to >> the single label created in the template page. This time in addition to >> the methods mentioned below also getStatelessHint gets called but still >> beforeRender etc are not called. >> >> The label is still fully rendered. As Martin requested I created a JIRA >> issue for this with my quickstart attached. The issue can be found here >> https://issues.apache.org/jira/browse/WICKET-3854 >> >> Please let me know if that is sufficient or how I can provide more >> information. >> >> Am 30.06.2011 19:04, schrieb Igor Vaynberg: >>> >>> just a hunch, but if the component to which the behavior is attached >>> to is not visible then none of the methods like before/after render >>> will be called since component is not rendering. >>> >>> -igor >>> >>> On Thu, Jun 30, 2011 at 9:48 AM, Christian >>> Huber<[email protected]> wrote: >>>> >>>> I tried adding a dummy implementation of that interface that logs every >>>> method call to custom subclass of link. While the links get rendered >>>> regularly the only methods that get invoked are isTemporary, bind, >>>> isEnabled >>>> and detach. All other methods are never called, am I missing >>>> something here? >>>> >>>> >>>> Am 30.06.2011 17:35, schrieb Igor Vaynberg: >>>>> >>>>> mixin IComponentConfigurationBehavior (1.4.17+ i believe) and >>>>> implement visibility toggling in onconfigure(component) of your >>>>> behavior. >>>>> >>>>> -igor >>>>> >>>>> On Thu, Jun 30, 2011 at 7:03 AM, Christian Huber<[email protected]> >>>>> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I wanted to use a Behavior to customize the components in my >>>>>> application >>>>>> (Wicket 1.4.2) by modifying some properties in the behaviors >>>>>> beforeRender >>>>>> method. >>>>>> >>>>>> But I had to find that this method is never called, neither is >>>>>> afterRender. >>>>>> The other methods of the behavior are invoked but those are not >>>>>> suitable >>>>>> for >>>>>> my needs (can't modify visibilty e.g. because that yields an >>>>>> exception). >>>>>> >>>>>> I found an bug entry about this problem and acording to the >>>>>> comments this >>>>>> seems to be a conecptual problem and won't be fixed. >>>>>> >>>>>> So I was wondering if there is a suitable alternative to be used >>>>>> instead >>>>>> of >>>>>> a behavior. For example I would like a component to decide for >>>>>> itself if >>>>>> it >>>>>> should be visible in the current context by evaluating stuff like >>>>>> login >>>>>> status of the user or it's content. >>>>>> >>>>>> Would be great if I could get some pointers on how to do this in a >>>>>> sensible >>>>>> way with wicket. >>>>>> >>>>>> Cheers, >>>>>> Chris >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
