Results 1 to 2 of 2

Thread: [PR2] delete config.listeners - purposeful behavior?

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Sencha User Surykat's Avatar
    Join Date
    Jul 2011
    BIALYSTOK, Poland
    Vote Rating

    Default Answered: [PR2] delete config.listeners - purposeful behavior?

    I have scenario in my app that allows me to open a detailed view multiple times during a itemdoubletap listener of a list. The event shows another view, which have a 'close button' that allows user to get back to list.

    My problem is coused of that I am moving my application from Sencha Touch 1.0 and I have listeners declared in list configuration. The problem what I have observed in PR2 (in PR1 everything was working fine) is that my listeners declared in list configuration are deleted after first assignment to list/view.

    The code is: (in debug version):
        constructor: function(config) {
            if (config) {
                if ('listeners' in config) {
                    delete config.listeners;
                if ('bubbleEvents' in config) {
                    delete config.bubbleEvents;
            return this;
    Is it a purposeful behavior and a good behavior to deleting that config? What should I do to avoid further problems with something like this? Couse now, of course, I could comment that lines and problem dissapear. But it is not a solution in case to Yours further releases.

    Is is possible to check original configuration for listeners in component and restoring them if nothing change them during application lifecycle?

  2. In PR2 we made the constructor of Observable mixin to be executed before the constructor of the target class to ensure all given listeners are added before any other config item is initialized. Deleting config.listeners after it's already been processed is merely a performance optimization so that it doesn't get double-processed again when the target class invoke initConfig().

    We are aware of the issue you're encountering as a consequence of this change, when the same config object reference is reused again in multiple instantiation. A temporary workaround is to not use the same config reference while we're looking into a more permanent solution.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts