4.1 RC3 - Ext.form.field.Trigger has no trigger event

[themightychris]

Ext.form.field.Trigger suggests that you override onTriggerClick to implement some behavior for the trigger.

NO events are fired though, so I'm putting onTriggerClick: function(e) {this.fireEvent('trigger', this, e)}; in all my views. The trigger class should always fire a "trigger" event in addition to calling the onTriggerClick method so that controllers can wire them without needing a handler function dropped into the view.

Update:
Here's a patch I created to add the 'trigger' event to all Trigger components that also implement a config option called triggerOnEnter

[skirtle]

In the general case, events get a little awkward when the TriggerField has multiple triggers.

I think TriggerField is viewed as an abstract class and that makes overriding a method the correct way to go. The subclass would then be responsible for firing suitable events for the controller.

[themightychris]

Where's the problem with a single builtin trigger event that gets passed something to let listeners identify which trigger was clicked? Many components work like that already

I can do everything I need with the trigger class by configuring it with a lazy object literal inside my view, I don't see why I should have to create a subclass to use it anymore than I should for a textfield or combobox. While subclassing makes sense when adding significant or reusable properties/behaviors, everywhere else in the framework it's made to be the exception not the rule. One fireEvent line will give controllers all they need to wrangle triggerfields consistently with how every other field is controlled.

[skirtle]

Where's the problem with a single builtin trigger event that gets passed something to let listeners identify which trigger was clicked? Many components work like that already

Deciding on the 'something' is the tricky bit. I suppose it could pass the trigger index so long as you assume that the notion of a trigger index makes sense for all trigger fields. There's an edge case straight out of the box with spinners but I'm sure some convention can be dreamt up.

I can do everything I need with the trigger class by configuring it with a lazy object literal inside my view, I don't see why I should have to create a subclass to use it anymore than I should for a textfield or combobox. While subclassing makes sense when adding significant or reusable properties/behaviors, everywhere else in the framework it's made to be the exception not the rule. One fireEvent line will give controllers all they need to wrangle triggerfields consistently with how every other field is controlled.

Yeah, I see what you mean. I think TriggerField was intended to be abstract but in practice it doesn't need to be. If it's used as a search field rather than as a picker or clear button then it makes sense to handle the trigger click in a controller.

[slemmon]

I put in a feature request a while back. Mitchell wrote a story for it. Don't know what happens beyond that, but the request is in the hopper it seems.
http://www.sencha.com/forum/showthre...hlight=trigger