please add a request to jira to do this, referencing or pasting this email. i dont think we can do this for 1.4 as it would change the semantics of isEnabledAllowed() transparently. but, in 1.5 we can make the change.
-Igor On Mon, Mar 28, 2011 at 6:59 AM, Emond Papegaaij <[email protected]> wrote: > Hi all, > > We are trying to migrate our projects from overriding isVisible and isEnabled > to the new onConfigure method, but are having some problems with the new API. > > I'll start with explaining the old situation. We find it good practice to > always call super.isVisible() in an overriding isVisible method. A typical > implementation would look like this: > > public class MyComponent extends WebMarkupContainer { > public boolean isVisible() { > return super.isVisible() && isConditionSatisfied(); > } > } > > Doing things this way, ensures the component will never be visible when the > condition is not satisfied, nor when the component is explicitly hidden with > setVisible(false). > > Trying to convert this to the new API, we started with: > > public class MyComponent extends WebMarkupContainer { > protected void onConfigure() { > super.onConfigure(); > setVisible(isVisible() && isConditionSatisfied()); > } > } > > However, we soon realized this will not work because a hidden component can > never become visible again. Even when the condition is satisfied, isVisible() > will still be false, causing the component to remain hidden. Therefore, our > second attempt was to remove the call to isVisible(): > > public class MyComponent extends WebMarkupContainer { > protected void onConfigure() { > super.onConfigure(); > setVisible(isConditionSatisfied()); > } > } > > This, however, suffers from another problem: manual setVisible(...) calls are > now ignored. The visibility flag is always overridden by onConfigure. On our > third attempt, we decided to use the visibilityAllowed flag for onConfigure, > like this: > > public class MyComponent extends WebMarkupContainer { > protected void onConfigure() { > super.onConfigure(); > setVisibilityAllowed(isConditionSatisfied()); > } > } > > This works great. It mixes with calls to setVisible. It even mixes well with > isVisible overrides in subclasses. However, this approach only works for > component visibility. There is no setEnabledAllowed. There is a > isEnableAllowed(), but it is security related (the counterpart of > isRenderAllowed()). > > Would it be possible to add a new property to Component (both in 1.4 and 1.5): > enabledAllowed? This property would have a final getter (isEnabledAllowed) and > setter (setEnabledAllowed), just as with visibilityAllowed. The naming of > isEnableAllowed() would be a bit unfortunate, but I don't think that method > can be changed. It is part of the public API. This new property would make it > significantly easier to move to onConfigure. > > > Best regards, > Emond Papegaaij >
