Как асинхронной подгрузить компонент
Здравствуйте, Мне нужно асинхронно запустить приложение. Сейчас это делается в файле 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, время: 04:22. |