Предположим у нас есть класс object1:

var object1 = {
    property1 : 'Свойство 1',
    method1 : function() {
        alert(this.property1);
    }
}

При вызове object1.method1(); У нас выпадет alert с текстом: “Свойство 1″.

Создадим другой класс, назовем его object2

var object2 = {
    property1 : 'Свойство object2',
}

Теперь попробуем выполнить следующий код: object1.method1.call(object2); У нас выпадет alert с текстом: “Свойство object2″. Почему так получилось ? Мы указали функции при вызове “scope” объект, то есть объект, который функция присвоила this, как будто бы мы написали в теле функции this = object2; поэтому текущим у нас оказался объект object2, а не object1.

Когда у нас нет возможности вызывать метод call, это например, происходит при создании новой функции, в ExtJS есть специальный метод createDelegate, который так же принимает в качестве аргумента “scope” объект, в данном случае object2:

var newFunction = object1.method1.createDelegate(object2);

Теперь если мы вызовем нашу созданную функцию newFunction(); то мы также получим alert c текстом: “Свойство object2″.

Иногда “scope” объект удобно указывать через свойство объекта. Допустим у нас есть метод в классе AjaxObject, представляющий из себя ajax запрос, и есть свойство класса property1:

var AjaxObject = {
    property1: 'Свойство 1',
    scope: this,
    sendAxaj: function() {
        Ext.Ajax.request({
            url: '/api.php/' ,
            method: 'GET',
            success: this.ajaxSuccess,
            params: post,
            scope: this
        });
    },
    ajaxSuccess: function(response) {
        alert(this.property1);
    }
}

Для того, чтобы мы могли каждый раз использовать методы и свойства главного класса AjaxObject, мы прописываем объектам свойство scope: this. Это в первом случае позволяет нам легко использовать метод обратившись через this.ajaxSuccess. А во втором случае, в callback функции использовать свойство главного класса AjaxObject this.property1.

Scope и createDelegate() является незаменимой вещью при построении больших приложений методом пред настроенных классов.

Важно.

Если вы этого еще не сделали, обязательно прочитайте первую часть и вторую часть этой статьи. Без этого будет очень трудно объяснить (или даже невозможно), а для вас понять, что написано в этой части.

Вступление.

Помогая на форуме, и читая код людей, которые делали ошибки при наследовании ExtJS классов, я обратил внимание на ошибки, которые пользователи обычно делают. Поэтому я решил написать эту статью, в которой буду собирать эти ошибки, и объяснять как их решать. Я имею ввиду что я не буду создавать больше частей этой статьи, а буду добавлять найденные ошибки сюда, вместо того чтобы бесконечно создавать части 4, 5 и т.д.

Наиболее распространенными источниками ошибок являются:

1. Ненужное наследование.
2. Добавление объектов к прототипу.
3. Жесткая привязка к id.

Ненужное наследование.

Основными причинами наследования являются:

1. Повторное использование.
2. Добавление функциональности.
3. И то и другое.

поэтому мы наследуем, если нам необходимо создать компонент для многократного использования или нам нужно добавить новый функционал классу (новые методы) или и то и другое. Если мы говорим о повторном использовании, наследование может быть простым:

MyPortlet = Ext.extend(Ext.Panel, {

anchor:'100%'

,draggable:true

,defaultType:'mygraph'

});

Вы видите что получается ? Мы будем использовать класс MyPortlet много раз, поэтому вместо того что писать каждый раз в приложении в 10000 строк эти строчки, мы просто 100 раз вызовем пред настроенный объект и сэкономим 297 строк кода.

Другая польза этого метода состоит в том, что если мы хотим изменить тип с ‘mygraph’ на ‘mygraph_new’, нам надо лишь поменять код в классе, который мы используем, это избавит нас от поиска и замены это же параметра в 100 мест кода.

(Ну 100 раз это конечно преувеличение, но экономия все равно будет).

Если говорить о добавлении нового функционала, то вот простой пример:

MyPanel = Ext.extend(Ext.Panel, {

onRender:function() {

MyPanel.superclass.onRender.apply(this, arguments);

alert('Rendered');

}

});

Здесь мы добавили новую логику к Ext.Panel, теперь у нашего класса больше возможностей, чем раньше.

Во всех других случаях использовать наследование нет необходимости.

Добавление объектов к прототипу.

Для начала выполним следующий код:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link rel="stylesheet" type="text/css" href="ext/resources/css/ext-all.css">
<script type="text/javascript" src="ext/adapter/ext/ext-base.js"></script>
<script type="text/javascript" src="ext/ext-all-debug.js"></script>
<title id="page-title">Extending Error: Object in prototype</title>
<script type="text/javascript">
Ext.BLANK_IMAGE_URL = 'ext/resources/images/default/s.gif';
Ext.onReady(function() {
MyPanel = Ext.extend(Ext.Panel, {
layout:'fit'
,panelConfig: {
bodyBg:'red'
}

,initComponent:function() {
var config = {
bodyStyle:'background-color:' + this.panelConfig.bodyBg
}; // eo config object

// apply config
Ext.apply(this, Ext.apply(this.initialConfig, config));

MyPanel.superclass.initComponent.apply(this, arguments);
} // eo function initComponent

,applyBackground:function(color) {
this.panelConfig.bodyBg = color;
this.body.applyStyles({'background-color':color});
} // eo function applyBackground

}); // eo extend

var p1 = new MyPanel({
title:'Panel with Blue Background'
,renderTo:Ext.getBody()
,width:240
,height:160
});

p1.applyBackground('blue');

var p2 = new MyPanel({
title:'Panel with Red Background'
,renderTo:Ext.getBody()
,width:240
,height:160
});

});
</script>
</head>
<body></body>
</html>

Чего мы ожидаем ? Это написано в title панелей: Верхняя панель (p1) должна быть с синим бэкграундом, потому что мы установили ей этот параметр после того как создали объект. А у нижней панели (p2) должен быть красный бэкграунд, потому что он стоит по умолчанию в классе MyPanel.

Но она получается тоже голубой!!! Почему ? Причина проста panelConfig  это объект, который создается при определении класса и он добавляется к прототипу MyPanel. Объекты (массивы тоже) доступны по ссылке, получается что p1 и p2 используют один и тот же panelConfig. Устанавливая свойство bodyBg в методе applyBackground мы изменяем panelConfig. Поэтому мы создаем панель p2 с таким же голубым цветом.

Здесь вы сразу увидели ошибку, но устранение этой ошибки может занят у вас недели в реальных приложениях. Представьте например, что у вас прототип класса store.

Жесткая привязка к id.

Очень простой, но смертельной ошибкой является жесткая привязка наследуемого класса или его items, tollbars, buttons объектов к определенному id. Если мы жестко привязываемся к определенному id, мы не сможем создать несколько экземпляров нашего класса, ведь так ?

Вместо заключения.

Это пока все, но если я найду еще какие-либо ошибки, я обязательно добавлю их выше.

Оставайтесь с нами!

Источник: http://blog.extjs.eu/know-how/writing-a-big-application-in-ext-part-3/

Не забудьте прочитать первую и вторую часть этой статьи.

Важно.

Если вы этого еще не сделали, обязательно прочитайте первую часть этой статьи. Без этого будет очень трудно объяснить (или даже невозможно), а для вас понять, что написано в этой части.

Вступление.

Прошел уже практически год, с того момента, как я опубликовал первую часть моей статьи. Я успешно использую концепцию пред настроенных классов, чтобы писать реально большие приложения (~150 .js файлов ~60000 строк кода, не считая серверного кода и .css файлов). Приложение полностью модульное, каждый класс это отдельный файл, словом мой способ доказал что он упрощает разработку, организацию кода и отладку.

К сожалению, не все было хорошо у других, кто использовал мой подход, они сталкивались с различными проблемами и Ext Support Team обрабатывали их проблемы и просьбы о помощи. Все это привело в к тому, что мой подход стали называть “абсолютная мерзость” и было сказано, что “это создает проблемы”.

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

В любом случае, есть какая-то нелогичность, что я могу использовать данный подход, а кто-то нет.

Так я стал смотреть глубже в причину ошибок и выделил некоторые из них с которыми пользователи могут столкнуться при разработке. Я также буду писать на тему “делать” или “не делать” и когда надо использовать пред настроенные классы, а когда нет. Я не буду сравнивать мой метод с другими (Метод Фабричных функций, прямой метод, загрузка по требованию и другие), потому что 1) я их не использую и 2) я не хочу превратить эту статью в очередной холивар между пользователями Linux и Windows.

Это в полной мере зависит от вас какой способ вы выберете. Однако, если вы выберете мой способ, то следуйте правилам, которые я хочу изложить.

Наиболее распространенные источники ошибок.

• Бездумный копи-паст
• Расширение класса базирующегося не на Ext.Component
• Не вызываются родительские методы
• initialConfig
• Слушатели событий
  

Бездумные копи-пастеры.

Вы знаете этих людей ? Они пишут на форуме:

Мне нужно перетащить текст с Tree на Grid, дай pliz полный рабочий codez.

И если кто-то и альтруистов пишет им фрагмент его “codez”, чтобы помочь ему, то в ответ будет:

Твой код не работает, помоги мне, мой менеджер хочет чтобы все работало.

Вы ведите, что происходит, такой “разработчик” , получив код на форуме скопипастил его, без задней мысли, не понимая, что этот код вообще делает, может даже он не изменил URL для своего сервера, и конечно же все не работает.

Это конечно крайности (но они случаются не столь редко, как вы могли подумать), тем не менее бездумный копи-паст может перевести лишь к разочарованиям.

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

Правило: Делайте копи-паст, но всегда с пониманием того, что делает код.

Расширение класса основанного не на Ext.Component.

Если класс ExtJS не наследуется от Ext.Component, функция initComponent  (Инициализатор компонента), не вызывается, таким образом код, который вы напишете в этой функции никогда не будет выполнен. Вот фрагмент кода из конструктора класса Ext.Component:

this.getId();
Ext.ComponentMgr.register(this);
Ext.Component.superclass.constructor.call(this);

if(this.baseAction){
this.baseAction.addComponent(this);
}

this.initComponent();

ExtJS классы которые не наследуются от Ext.Component не имею строчки this.initComponent(); в своем исходном коде.

Правило: Всегда проверяйте, наследуется ли класс, который вы хотите пред настроить, от класса Ext.Component. Вы должны использовать другой подход, если это не так.

Не вызываются родительские методы.

Часто случается так, что вы не только добавляете несколько методов в наследуемый класс, но так же вы изменяете уже существующие методы. initComponent – первый пример,  onRender, afterLayout, и другие (но и не только они) часто переопределяемые методы.

Эти методы уже есть в вашем классе и в родительском, от которого вы его наследуете, поэтому, если вы забудете строчки:

// in initComponent override
YourExtension.superclass.initComponent.apply(this, arguments);

// or in onRender override
YourExtension.superclass.onRender.apply(this, arguments);

// or in afterLayout override
YourExtension.superclass.afterLayout.apply(this, arguments);

ваш класс работать не будет.

Правило: Никогда не забывайте вызвать родительский метод, если вы уверены в том, что вы делаете.

initialConfig.

Конструктор класса Ext.Component сохраняет переданный ему конфиг, как свойство initialConfig:

/**
* This Component's initial configuration specification. Read-only.
* @type Object
* @property initialConfig
*/
this.initialConfig = config;

Ext.apply(this, config);
this.addEvents(/* abbreviated for clarity */);
this.getId();
Ext.ComponentMgr.register(this);
Ext.Component.superclass.constructor.call(this);

if(this.baseAction){
this.baseAction.addComponent(this);
}

this.initComponent();

Вы видите, что происходит ? Конструктор сохраняет initialConfig до того как выполняется метод initComponent. Таким образом весь ваш конфиг написанный в методе initComponent не сохраняется. Я не заметил этого в первой версии моих шаблонов и примеров, главным образом потому, что есть всего лишь несколько классов, которые используются свойство initialConfig и даже в этих классах вызов initComponent не правильным способом, вызывает ошибку крайне редко. Следующие классы используют свойство initialConfig:

• AnchorLayout
• BorderLayout
• Action
• GridPanel
• Tip
• Combo
• Form

Сейчас я обновил все мои примеры, расширения, шаблоны и основной сайт, чтобы включить в него этот “магический” шаблон:

// create config
var config = {
// put your config here
}; // eo config object

// apply config
Ext.apply(this, Ext.apply(this.initialConfig, config));

// call parent
YourExtension.superclass.initComponent.apply(this, arguments);

Правило: Убедитесь, что ваш класс-потомок сохраняет свойство initialConfig.

Слушатели событий.

Если вы попытаетесь установить обработчики событий, через свойства в конфиге, они не будут работать. Почему ? Ответ опять находится в порядке выполнения действий конструктора Ext.Component:

Ext.Component.superclass.constructor.call(this);

if(this.baseAction){
this.baseAction.addComponent(this);
}

this.initComponent();

Как вы видите конструктор вызывает своего родителя, который является классом Ext.util.Observable до initComponent, а Ext.util.Observable конструктор выполняет:

Ext.util.Observable = function(){
if(this.listeners){
this.on(this.listeners);
delete this.listeners;
}
};

Таким образом любые слушатели событий в initComponent игнорируются.

Существует простой способ решить эту проблему. Положите метод конструктора класса в ваш класс потомок:

constructor:function(config) {
// parent constructor call pre-processing - configure listeners here
config = config || {};
config.listeners = config.listeners || {};
Ext.applyIf(config.listeners, {
// add listeners config here
});

// call parent constructor
AnExtension.superclass.constructor.call(this, config);

// parent constructor call post-processing

} // eo function constructor

и определяйте слушателей событий в нем.

Правило: Назначайте слушателей событий в методе-конструкторе.

Заключение.

Если вы решите использовать мой способ написания больших приложений на ExtJS, следуйте следующим правилам:

1. Применяйте копи-паст всегда с полным пониманием того, что делает код.
2. Всегда проверяйте наследуется ли класс который вы хотите пред настроить от Ext.Component. Вы должны использовать другой подход, если это не так.
3. Никогда не забывайте вызвать родительский метод, если вы уверены в том, что делаете.
4. Убедитесь что ваш класс сохраняет свойство initialConfig.
5. Назначайте слушателей событий в методе-конструкторе.

Удачного наследования!

Источник: http://blog.extjs.eu/know-how/writing-a-big-application-in-ext-part-2/

Предисловие

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

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

Я только хочу сказать, что мой подход, позволяет легко структурировать и писать красивый код. Он “реально работает”!

Что можно назвать большим приложением ?

Если у вас есть Viewport с BorderLayout, grid и формы – все в одном файле, это конечно, небольшое приложение. А вот если у вас десятки окон с формами, гридами и все это в 10 файлах, это уже не маленькое приложение, правда ?

(У немцев есть забавное выражение Jein, которое является производным от Ja = Да и Nein = Нет )

Ответ на вопрос поставленный выше это Jein (Прим. переводчика: Русское Да-нет наверное тоже является эквивалентом этого немецкого слова). Нет однозначного ответа, когда приложение становится большим, оно становится большим, когда вы считаете, что оно стало большим. Этот момент обычно наступает, когда вы уже не можете ориентироваться в ваших файлах, когда вы перестаете понимать как ваши компоненты в приложении соотносятся друг с другом. Нужно также представлять что будет, если с вашим кодом начнет работать программист в 2 -3 раза менее опытный чем вы.

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

Самое лучше – начинать писать приложение со словами: “Я начинаю писать большое приложение!”.

Файлы и папки.

Это необходимо организовать в первую очередь. Нужно всегда начинать с ServerRoot директории настроенной в Apache или каком-нибудь другом HTTP сервере, все описанные далее папки идут относительно нее.

. /css(опционально ссылка)

. /ext (ссылка)

. /img (ссылка)

. /js

index.html

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

* css будет содержать все ваши таблицы стилей. Если у вас есть глобальные таблицы стилей с фирменными цветами и шрифтами можно создать в CSS каталоге ссылку.

* ext ссылки на дерево ExtJS библиотек разных версий.

* img ссылки на изображения. Он может содержать также подкаталоги.

* js будет содержать все скрипты вашего приложения.

* index.html файл HTML, который является отправной точкой вашего приложения. Вы можете назвать его как хотите, и вам может понадобиться еще несколько файлов, например, для авторизации.

* По желанию, вы можете создать директорию или ссылку на ваши серверные скрипты (у меня есть. / classes).

(Прим.Переводчика: ссылки для Linux).

index.html

Примерное минимальное содержимое файла index.html выглядит следующим образом:

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

<link rel="stylesheet" type="text/css" href="./ext/resources/css/ext-all.css">

<link rel="stylesheet" type="text/css" href="./css/application.css">

<script type="text/javascript" src="./ext/adapter/ext/ext-base.js"></script>

<script type="text/javascript" src="./ext/ext-all-debug.js"></script>

<script type="text/javascript" src="./application.js"></script>

<title>A Big Application</title>

</head>

<body></body>

</html>

application.js

Нам нужен файл в котором будет размещена функция onReady, давайте назовем его application.js. Минимальное содержание выглядит так:

/**

* An Application

*

* @author    Ing. Jozef Sakáloš

* @copyright (c) 2008, by Ing. Jozef Sakáloš

* @date      2. April 2008

* @version   $Id$

*

* @license application.js is licensed under the terms of the Open Source

* LGPL 3.0 license. Commercial use is permitted to the extent that the

* code/component(s) do NOT become part of another Open Source or Commercially

* licensed development library or toolkit without explicit permission.

*

* License details: http://www.gnu.org/licenses/lgpl.html

*/

/*global Ext, Application */

Ext.BLANK_IMAGE_URL = './ext/resources/images/default/s.gif';

Ext.ns('Application');

// основная точка входа нашего приложения

Ext.onReady(function() {

Ext.QuickTips.init();

Здесь будет код вызова основного класса приложения

});

// eof

Ваш header и footer может быть различным, но уверен, вы должны установить параметр Ext.BLANK_IMAGE_URL, чтобы он указывал на картинку на локальном сервере. Это путь к 1 × 1px прозрачной картинке, которая используется Ext для пустых областей, если параметр указывает на неправильное место, у вас могут возникнуть различные проблемы – такие, как отсутствие изображения-переключателя у Combobox, либо отсутствие иконок.

Вам также может понадобиться создать новую глобальную переменную-объект для приложения (в данном случае это Application).

Вы должны быть уверены, что Ext.onReady, это начало вашего приложения – место, где вы пишете его инициализацию.

css/application.css

Вы будете хранить ваши css стили в этом файле. Если вам нужно всего лишь несколько правил, то может показаться, что нет необходимости создавать отдельный файл для них, и что это хорошая идея положить их в тег <style> в заголовке.

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

Как делать Неправильно!

Что мы обычно делаем когда узнали основы, правильно, начинаем писать код:

var vp = new Ext.Viewport({
layout:'border'
,items:[
new Ext.grid.GridPanel({
store:new Ext.data.Store({
proxy:new Ext.data.HttpProxy({ ...

Подождите минутку. Так мы очень скоро получим более 10000 строк в нашем файле application.js, а это то, что мы хотим в самую последнюю очередь. Очевидно мы что-то пропустили, если мы создаем такой большой файл, почему бы нам вообще не написать все в index.html.

Правильное решение - разделить все!

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

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

Предварительно настроенные классы.

Итак, сейчас, когда вы определились со структурой вашего приложения, вы начнете писать первый из компонентов. Но каким образом ? Лучше решение - это расширить классы компонентов ExtJS, добавить в них конфигурационные параметры. Я называю такие объекты пред настроенными компонентами, они редко добавляют какой-то функционал в стандартный класс ExtJS, но главная цель этого - пред настройка. Например чтобы иметь преднастроенный grid, с собственномы ColumnModel, store, sorting option, editor и т.д.  делаем следующее:

Application.PersonnelGrid = Ext.extend(Ext.grid.GridPanel, {
border:false
,initComponent:function() {
var config = {
store:new Ext.data.Store({...})
,columns:[{...}, {...}]
,plugins:[...]
,viewConfig:{forceFit:true}
,tbar:[...]
,bbar:[...]
}; // eo config object

// Применяем config
Ext.apply(this, Ext.apply(this.initialConfig, config));

Application.PersonnelGrid.superclass.initComponent.apply(this, arguments);
} // eo function initComponent

,onRender:function() {
this.store.load();

Application.PersonnelGrid.superclass.onRender.apply(this, arguments);
} // eo function onRender
});

Ext.reg('personnelgrid', Application.PersonnelGrid);

После создания преднастроенного класса мы можем его использовать следующим образом:

var win = new Ext.Window({
title:'Personnel'
,widht:600
,height:400
,items:{xtype:'personnelgrid'}
});
win.show();

Что мы сделали ? Мы расширили класс Ext.grid.GridPanel создав новый класс Application.PersonnelGrid и мы зарегистрировали его как xtype с именем personnelgrid.

Мы настраиваем класс GridPanel всеми необходимыми функциями, которые нужны, чтобы этот класс стал объектом PersonnelGrid. С этого момента у нас появился новый компонент, строительный блок нашего приложения, который мы можем использовать в любом месте ( в окне, в таблице, самостоятельно – отдельно от всего остального). Мы можем создать его двумя способами:

//Напрямую через объект
var pg = new Application.PersonnelGrid();

// или используя его xtype имя
var win = new Ext.Window({
items:{xtype:'personnelgrid'}
,....

});

Организация пред настроенных классов.

Приведенный выше код не нужно помещать в функцию OnReady, поскольку он не имеет ничего общего со структурой DOM, а лишь создает новый объект JavaScript. Поэтому он может и должен быть записан в отдельный файл (js/Application.PersonnelGrid.js) и должен быть включен в заголовок index.html следующем образом:

<script type="text/javascript" src="./js/Application.PersonnelGrid"><script>

Пока все хорошо, у нас практически все на своем месте, и почти все что нам необходимо в дальнейшем это писать вот такие пред настроенные классы, помещать их в каталог ./js, добавлять в index.html, и собирать приложения из этих компонентов, как мозайку из составных частей.

Выглядит неплохо, правда ?

Хотя есть еще кое что, что необходимо знать.

Коммуникация между компонентами.

Представьте себе, что нам нужно разместить в одном месте справа TabPanel (панель с вкладками), а слева список ссылок. Нажимая на ссылку мы будем создавать новую владку на панели справа. Куда мы должны поместить обработчик нажатия на кнопку слева или справа ? В TabPanel или в списке ссылок ?

Не в одном из них. Почему ? Если у нас есть предварительно настроенный класс, который создает список ссылок и поместим наш обработчик после этого кода, то он не будет знать ничего о TabPanel. В тоже время он должен использовать TabPanel.

Если мы поместим обработчик в TabPanel, то будет тоже самое, он не будет знать на какую именно ссылку мы нажали.

Единственный компонент, который знает все о существовании списка ссылок и TabPanel – это их контейнер, он может фиксировать события этих двух компонентов, только туда мы можем поместить нужный нам обработчик.

Итак, что мы должны делать ? Наш главный контейнер должен слушать событие от списка ссылок и должен в ответ на это событие создавать кладки в TabPanel. Компонент который описан в этом примере можно увидеть здесь Saki’s Ext Examples.

Production системы.

Когда мы пишем таким образом большое приложение у нас в скором времени в index.html образуется множества .js вложений (у меня в одном приложении около 80, и продолжает с каждым днем расти). Это может снизить быстродействие системы.

Лучший способ решить эту проблему, объединить все файлы в один при публикации вашего приложения. Это лучше всего сделать с помощью программы для уменьшения и склеивания .js файлов (Прим.переводчика: я использую YUI Compressor в Eclipse).  Кроме того на сервере вам не нужна debug версия ExtJS, которую вы используете при разработке. В конечном итоге на сервере у вас должно получится следующее:

* ext-all.js
* app-all.js and
* application.js

Заключение.

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

Удачного программирования!

Источник: http://blog.extjs.eu/know-how/writing-a-big-application-in-ext/

Часть 2 и Часть 3.