Как асинхронной подгрузить компонент
Здравствуйте, Мне нужно асинхронно запустить приложение. Сейчас это делается в файле app.js
/**
* Иницализация загруженных классов
*
*/
Ext.onReady(function() {
og.Localizator.init()
.then(function() {
// контроль доступа
Ext.define('og.override.Component', {
override: 'Ext.Component',
listeners: {
beforerender: function() {
if (this.ogAccessPath) {
console.log('this.ogAccessPath', this.ogAccessPath);
}
return U.access.testByName(this);
},
},
});
})
.then(function() {
var c = og.widgets.themechanger.ThemeChangerController;
c.changeThemeGlobal();
})
.then(function() {
Ext.QuickTips.init();
Ext.window.MessageBox.prototype.closeToolText = L({ ru: 'Закрыть панель', en: 'Close panel' });
Ext.setGlyphFontFamily(Glyphs.DEFAULT_FONT_FAMILY);
})
.then(createApp)['catch'](function(err) {
console.error(err);
alert('app start has failed');
});
});
/**
* Запуск приложения
*
*/
function createApp() {
Ext.application({
name: 'og',
extend: 'og.Application',
requires: [
'og.view.main.Main'
],
mainView: 'og.view.main.Main'
}
Можно ли вынести инициализацию загруженных классов в отдельный файл, например в Application.js и в какое место? |
Не делайте так, не надо. Вы себе такую яму копаете с этим подходом, что просто ох и ах. Я даже не буду пытаться перечислять все подводные грабли на этом тернистом пути, пальцы можно сточить.
Хотя каноничного подхода не существует, единственный практически доступный подход, на мой взгляд, таков: а) Используйте декларативный подход по-максимуму б) Создавайте классы собственных виджетов с нужной конфигурацией вместо конфигурирования экземпляров ц) Не морочтесь загрузкой "только нужных" классов, это ересь и с точки зрения безопасности, и с точки зрения производительности д) Создавайте полную сборку JavaScript со всеми классами вашего приложения и фреймворка е) Валидируйте каждый чих на сервере. Иначе будет ад и хаос. ф) После загрузки приложения и аутентификации пользователя запрашивайте с сервера большой JSON с конфигурацией дерева виджетов, и скармливайте его в Ext.create() или Ext.widget() Только так вы можете быть уверены в том, что пользователь видит только те элементы UI, которые ему положены по уровню авторизации. Если паранойя спать не даёт, то можно сделать несколько сборок приложения, по количеству основных уровней авторизации. В каждую сборку будут входить, соответственно, только те классы, которые потенциально доступны данному уровню. Но этот подход оправдан, только если абсолютно необходим и есть понимание, какой ценой в поддержке он будет даваться. У меня перед глазами были примеры, когда люди не то, что сборки JavaScript по уровням доступа разбивали, но и Direct API с сервера тоже отдавали под аутентификацию и с доступом в зависимости от уровня, чтобы "лишнее не светить". Это работает, но неизвестно, насколько такая паранойя оправдана с точки зрения безопасности. P.S. По странному совпадению, декларативные классы также и тестировать гораздо легче. Двух зайцев, да? :) |
| Часовой пояс GMT +3, время: 18:07. |