1. #1
    Sencha Premium Member
    Join Date
    Apr 2008
    Posts
    252
    Vote Rating
    26
    themightychris will become famous soon enough themightychris will become famous soon enough

      0  

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

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


    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
    Chief Architect @ Jarv.us Innovations
    Co-captain @ Code for Philly
    Co-founder @ Devnuts - Philadelphia Hackerspace

  2. #2
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,605
    Vote Rating
    326
    skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future

      0  

    Default


    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.

  3. #3
    Sencha Premium Member
    Join Date
    Apr 2008
    Posts
    252
    Vote Rating
    26
    themightychris will become famous soon enough themightychris will become famous soon enough

      0  

    Default


    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.
    Chief Architect @ Jarv.us Innovations
    Co-captain @ Code for Philly
    Co-founder @ Devnuts - Philadelphia Hackerspace

  4. #4
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,605
    Vote Rating
    326
    skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future

      0  

    Default


    Quote Originally Posted by themightychris View Post
    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.

    Quote Originally Posted by themightychris View Post
    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.

  5. #5
    Sencha - Support Team slemmon's Avatar
    Join Date
    Mar 2009
    Location
    Boise, ID
    Posts
    5,369
    Vote Rating
    200
    slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of

      0  

    Default


    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

Thread Participants: 2