Feature request: Add method HasEnabled.addEnabledChangeListener()

[archiecobbs]

Describe your motivation

We have lots of events that reflect changes in state of a component: value change, attach, detach, etc.

It seems like the "enabled" status is no different.

Why then is there not a way to listen for changes in the enabled status of a component?

Note, this should allow any component to be listened to; overriding onEnabledStateChanged() only works for "this" component, and only if you write a subclass.

Describe the solution you'd like

Define new ComponentEvent and add new method addEnabledChangeListener() to the HasEnabled interface.

Describe alternatives you've considered

There aren't any really short of hacking Vaadin itself.

Additional context

Here's a simple motivating example...

Suppose you have a form with two fields, where the second is dependent on the first.

For example:

• [] I'd like to sell my car
• Asking price: [ ]

The second field is only relevant if the first field is checked and enabled.

Currently, we can listen for whether it's checked or not, but we can't listen to whether it's enabled or not.

[Legioth]

It's a question about how often this would be useful vs bloating the API.

The attach and detach listeners is very useful because those things can be triggered by things not directly controlled by application code, such as sessions being expired. There are also cases where other parties are interested in knowing when a component gets attached, such as the way Collaboration Engine disables globally registered subscriptions to avoid leaking memory when the component that would be updated by the subscription is no longer attached.

Are there corresponding cases for the enabled state? I don't see how the example with the checkbox directly applies since the status of the text field is logically related to the value of the checkbox - if it's checked but disabled, then you can't take back selling the car but it's still relevant to provide a price. If there's application code that disables the checkbox under certain conditions, then the same application code could also disable the text field if appropriate.

[archiecobbs]

It's a question about how often this would be useful vs bloating the API.

Yeah that's what developers always say when they don't want to add something :)

But speaking seriously I also disagree with that statement. I think the right question is whether it makes the API more complete, correct and consistent.

if it's checked but disabled, then you can't take back selling the car but it's still relevant to provide a price.

That's true in one model, yes, but in a different model it's not true.

I'll try my best to explain.. apologies in advance if this is hard to follow.

Suppose we simply want disabled fields to "remember" their values. In other words, the checkbox might be disabled because selling your car is simply not an option (e.g., you are still renting it) and so whether you want to sell it and at what price are irrelevant. However, you put some values in there once before and we don't want to lose them.

In this case, if the checkbox is disabled, we don't want to give the user the idea that entering a new sale price is useful at the current time. So we want that field disabled too.

1. ⃞ I own my car
2. ⃞ I want to sell my car
3. The price for sale is ⃞

So we have two simple dependencies:

• Field 2 is dependent on field 1
• Field 3 is dependent on field 2

Suppose I check both checkboxes and then fill in a sale price.

Then I uncheck "I own my car".

I want fields 2 and 3 to automatically be disabled, but I want them to "remember" their values (i.e., they don't get reset).

You may say you prefer field 3 to stay enabled - that's fine, now we're just talking about a minor semantic or stylistic difference. But your preference does not invalidate my preference, right?

Now I know you will say "OK just add another listener from checkbox 1 to field 3". But in my real application field 3 knows nothing about field 1 - they are created and established independently. Field 3 only knows it is dependent on field 2. Field 2 only knows it is dependent on field 1.

In effect you would be saying "all fields must understand not just what other fields they depend on, but the transitive closure of those dependencies", but that's clearly unreasonable in general.

[enver-haase]

@archiecobbs while I like the idea of an enabled/disabled-change-listener.

(below can be considered off-topic for the sake of this ticket)
I do not like the idea of setting up a difficult-to-explain-and-even-harder-to-understand a number of checkboxes that may or may not know about other checkboxes with some partial control code of what to change where in case 'this' checkbox was clicked scattered among them.
Please consider https://cookbook.vaadin.com/ui-eventbus an event-driven architecture here. Let checkboxes be checkboxes without the knowledge of other checkboxes and introduce a 'higher' control layer with its code in one central place (in the cookbook example the VerticalLayout where the buttons are attached to knows what to do with them).