2013-05-13 6 views
7

ExtJS 4,1ExtJS Применение Событие WOES

Я побежал в немного загадкой, и хотелось бы услышать другие разработчики ввода по этому сценарию в отношении ExtJS событий и методов контроллера. Я понимаю, что эта тема неоднократно освещалась и обсуждалась, но я чувствую, что она может использовать немного больше.

В соответствии со стандартной практикой, я определяю слушатель событий в моей декларации init() метода контроллера следующим образом:

Ext.define("My.controller.Awesome", { 
init: function(application){ 
    /** Observe some Views */ 
    this.control({ 
     'my-awesome-view #saveButton':{ 
      click: this.saveMyData 
     } 
    }); 

    /** Listen for Events, too! */ 
    this.on({ 
     showAwesomeView: this.showMyAwesomeView 
    }); 

    /** Application events, what fun! */ 
    this.application.on({ 
     showThatAwesomeView: this.showMyAwesomeView 
    }); 
} 

Теперь, как я весело идти о кодировании некоторых функциональных возможностей в каком-либо другом контроллере, я считаю себя необходимостью позвонить showMyAwesomeView в My.controller.Awesome. Я могу сделать это в несколько различных способов ...

Ext.define("My.controller.Other", { 

    /* ... class definition */ 

    someImportant: function(){ 

     // I can do this (Approach #1) 
     this.application.getController("Awesome").showMyAwesomeView(); 

     // Or I can do this (Approach #2) 
     this.application.getController("Awesome").fireEvent("showAwesomeView"); 

     // Last but not least, I can do this (Approach #3) 
     this.application.fireEvent("showThatAwesomeView"); 
    } 
}); 

Для меня Approach # 3 чувствует самым «правильным». Моя проблема заключается в том, что, если я еще не создал экземпляр My.controller.Awesome, метод init() еще не запущен, и поэтому нет установленных слушателей, поэтому уволенное событие уходит в загадочную землю, о которой никогда не слышат.

я перегружена Ext.application.getController() позвонить controller.init() перед возвращением controller, поэтому контроллер имеет свой метод, называемый init, как только он будет загружен (обычно в виде зависимости в другой контроллер). Это плохо?

Чтобы сохранить время загрузки (мое приложение довольно велико), мои контроллеры и их зависимости загружаются по мере необходимости. Поэтому большинство моих контроллеров (и представлений, и хранилищ данных) не создаются, когда мое приложение сначала загружает , поэтому не init() 'ed, что делает обман широкомасштабных событий приложения весьма громоздкими.

Я чувствую, что, возможно, мне не хватает чего-то большого, или, может быть, мне просто нужно укусить пулю и обеспечить, чтобы мои контроллеры были инициализированы до начала соревнований. Я полагаю, что я мог бы также добавить абсолютно ужасное количество прослушивателей событий в основной файл приложения и обработать инициализирующие контроллеры, прежде чем называть их методы соответственно, но это кажется очень неаккуратным и сложным в обслуживании.

Любой вход был бы оценен, спасибо за ваше время!

+0

Интересно, полагаю, вы чувствуете, что метод 3 лучше всего, потому что он наиболее развязан, контроллер 2 не должен заботиться о том, какой контроллер должен выполнять требуемое действие. Но, если контроллер уже не доступен, кто-то должен знать. Может быть, вы можете создать какую-то таблицу маршрутизации на уровне приложения (какой контроллер прослушивает какие события), а fireEvent - инициализировать требуемый контроллер? –

+0

@AmitAviv Я кратко описал идею маршрутизации в моем вопросе, но кажется очень неряшливым иметь массивный список слушателей в главном файле приложения исключительно для обеспечения создания экземпляра контроллера перед вызовом требуемого метода. Я предпочел бы создать экземпляр контроллера вручную (в контроллере вызываемого абонента) перед запуском события. Спасибо за ваш вклад! –

+1

Я не имею в виду массивный список слушателей, я имею в виду таблицу, ключи - имена событий, значения - имена контроллеров .. fireEvent может быть перегружен для чтения таблицы и инициализации требуемого контроллера на основе таблицы. Я не уверен, что это очень хорошее решение, но я не вижу волшебного способа поддерживать развязку и ленивую загрузку и не зная о связи «event-controller». –

ответ

3

Подход № 3 (this.application.fireEvent ('showThatAwesomeView')) - отличное решение. Использование событий приложения приводит к тому, что контроллеры, которые не имеют никаких предположений о том, какая другая логика может быть добавлена ​​или удалена из приложения, связанного с этим событием.

Что касается вашей обеспокоенности в отношении того, что контроллеры были созданы во времени для правильной привязки к событиям, использование контроллера Ext.app.Application устранит это. Контроллер App инициализирует все указанные контроллеры, когда приложение инициализируется. Вы заметили озабоченность по поводу времени запуска, связанного с количеством контроллеров. В некоторых случаях я работал над многими приложениями с одной страницей, в которых есть десятки и даже сотни контроллеров. Поддержание любой минимальной логики инициализации должно уменьшить заметное замедление. Минимизированные и комбинированные скрипты вместо загрузки по требованию хорошо зарекомендовали себя для быстрого запуска приложений.

Избегание метода getController является хорошей практикой.Логика приложения, как правило, лучше организована при использовании событий приложений вместо логики, которая плотно соединяет контроллеры друг с другом.

+1

Я полностью согласен с вашими предложениями, хотя мне все еще немного нужно загрузить все мои контроллеры при запуске приложения. Поскольку загрузка хранилищ данных, как правило, является узким местом (я думаю?), Возможно, мне нужно разработать метод загрузки только определенных хранилищ данных и загрузки других только тогда, когда это необходимо. На данный момент я оставлю этот вопрос без ответа, но я буду отмечать ваш ответ как правильное, ожидая ответа на другие вопросы. Большое спасибо за ввод! –

+0

Хорошо, отлично. Отсрочка загрузки данных также очень полезна для ускорения загрузки исходного приложения. –

+0

Я принял ваш ответ, еще раз спасибо. Я разместил несколько связанных вопросов относительно сложных операций сохранения, если вы хотите предложить свой вклад :) http://stackoverflow.com/questions/16551901/extjs-and-complex-save-operations –

0
Ext.define('UD.controller.c1', { 
    extend: 'Ext.app.Controller', 
    refs: [ 
      { 
       selector: 'viewport', 
       ref: 'userview' 
      } 
      ], 
    init: function() { 
     console.log("initincontroller!!"); 
     this.control({ 
      'viewport > panel': { 
       render: this.onPanelRendered 
      } 
     }); 
    }, 
    onPanelRendered:function(){ 
     alert("rendered"); 
     UD.getApplication().fireEvent('myevent'); 
    } 
}); 



Ext.define('UD.controller.c2', { 
    extend: 'Ext.app.Controller', 
    refs: [ 
      { 
       selector: 'viewport', 
       ref: 'userview' 
      } 
      ], 
    init: function() { 
     console.log("initincontroller!!"); 
      UD.getApplication().on({ 
       myevent : this.doSomething 
      }); 
    }, 
    doSomething:function(){ 
     alert("controller2"); 
    } 
}); 
+0

Прокомментируйте код. – lpapp

Смежные вопросы