Последовательность определения alternateClassName
 

Здравствуйте!

Не могу понять, это баг или фича такая.

Ext.define("MyApp.Item", {	
	alternateClassName: "MyApp.Project.Item"	
});

Ext.define("MyApp.Project", {	
	alternateClassName: "MyApp.Project"	
});

В итоге выполнения кода получаем неприятность в виде:

MyApp.Project.Item === undefined

Иными словами, Сенча не предусмотрела вариант, когда альтернативные имена классов определяются в не совсем правильной последовательности.

Может я не догоняю и такая ситуация правильная?

Инструкция определения пространства имен не помогает:

Ext.namespace("MyApp", "MyApp.Project");

Нашел особенность именования классов, которая эту ситуацию исключает.

Надо вместо MyApp.Project.Item писать MyApp.project.Item. И тогда все заработает.

Но вопрос остается в силе. Баг или фича?

Ну вначале класс Item помещается в пространство имён MyApp.Project. Т.е. MyApp.Project - это объект, а не функция. Потом MyApp.Project превращается из пространства имён в класс (функцию). Всё, что было в простанстве имён пропадает вместе с классом Item.

fiddle

Я бы для начала ответил вопросом на вопрос: а зачем вам вообще alternateClassName? Это реликт давно ушедших дней, который в приложениях вообще не должен использоваться.

alternateClassName я использую для корневых классов. Например:

Сделал класс MyApp.lib.project.Project.

Хранится в папке lib/project - типа каталог пакета классов Проект.

Но удобнее юзать для него имя MyApp.lib.Project.

Остальные классы имеют вид MyApp.lib.project.*, например MyApp.lib.project.Item

В Ext JS кроме alternateClassName есть вообще хрень:

alias
xtype
type
ptype
и прочяя нечисть

Запутаться можно в этой хрени.

правда вещи типа ptype мне понравились, даже свои начал делать, например для хелперов сделал htype

Это не хрень, и путаться в ней не нужно. Это полезные инструменты, которыми можно (и нужно!) пользоваться, тогда и alternateClassName не понадобится вовсе. ;)

Если мы говорим о классах, то в общем случае есть два варианта создания объекта данного класса:

или по алиасу:

xtype это частный случай alias для компонентов (виджетов). Есть ещё много других пространств для алиасов: store.*, controller.*, etc.

Глубинный смысл всего этого добра в том, чтобы уйти от императивного стиля кодирования, когда вам нужно руками создавать все объекты. Вместо этого создавайте классы с конфигурацией, которая ссылается на алиасы, и не нужно будет хардкодить имена классов. По факту их вообще и не нужно использовать, если ваш проект использует Sencha Cmd. Модуль отслеживания зависимостей в Cmd уже весьма неплох, и даже requires можно в общем случае опустить: Cmd все зависимости найдёт за вас, в т.ч. вычислит по alias.

alternateClassName это мисфича, которую руки очень чешутся прибить, но к сожалению она сидит очень глубоко в class system, и выкорчёвывать её оттуда будет больнее, чем просто оставить и забыть. Но и использовать её в userspace тоже не нужно, это я вам как доктор говорю.

А как вы видите мой пример без использования alternateClassName?

Как использование основного имени класса? Вы же alternateClassName добавили, потому что печатать меньше. ;)

А если серьёзно, см выше: имя класса в общем случае вообще использовать не нужно. Его нужно задать один раз в Ext.define() для идентификации, и всё.

Откройте KitchenSink и вдумчиво посмотрите на примеры View, ViewControllers и прочих полезных штуковин.

Ясно. На досуге обмозгую эту идею. Жалко что Sencha Cmd не запустилась на Cloud9 (наверное из-за хилости бесплатного тарифного плана). Придется искать варианты, как это сделать.