МС параллельно работает над языками C# и VB.NET и в планах у них как раз унификация возможностей языков. Т.е. код будет одинаково работать что в шарпе, что в бейсике. Как тамошние дядьки говорят — выбор разработчика будет между look and feel шарпа и бейсика.
Обычно фреймворк сам регулирует жизненный цикл объектов, но в некоторых случаях необходимо самому их уничтожать. Делается это методом destroy, который определён в Ext.Component (базовый класс для всех виджетов). При этом можно отлавливать события элементов beforedestroy и destroy. Объект считается удалённым, если его свойство isDestroyed вернёт true.
Ext не безгрешен. Об этом говорят их сабмиты в свн. А хакать всё-таки приходится. Иногда (я описал случай в статье) это очень даже быстрый способ реализации той или иной функциональности, так что лучше предусмотреть возможность хака при проектировании. Есть альтернативный вариант — писать в сапорт. Они оперативно фиксят баги. В течении недели, если баг достаточно критичен. Но по моему опыту, во-первых, неделя — это очень долгий срок почти для любого проекта и, во-вторых, это означает что вы будете регулярно переходить с версии на версию. А это, опять же, огромный риск.
Смотря что вы подразумеваете под хаками. Баги в 3ей ветке, конечно, есть, но я ещё не сталкивался с критическими. Разве что в релиз кандидате, где просто не работал аккордеон в ie
К сожалению, если необходимо избежать перезагрузки приложения, приходится использовать предложенный разработчиками Ext'а стандартный метод локализации с перегрузкой объектов. Это очень неудобный метод, но о лучшем я ничего не знаю. Было бы замечательно, если бы кто-то написал статью на эту тему, так как предложенный метод локализации достаточно сложен.
Да, можно вообще Ext.apply не использовать, так как в данном контексте он ничего не даёт.
Касательно привязки привязки к версии — у нас всего лишь был разный опыт «общения» с фреймворком. У меня при апдейтах из репозитория, равно как и при официальном апдейте с 3.0.0 на 3.0.1 лезли пренеприятнейшие, непонятные ошибки. А я недокументированных возможностей, помимо конфигураций графиков, нигде не использовал (графики слабо документированы, приходилось смотреть их исходные коды). Таким образом, если есть даже малейший шанс заполучить хотя бы одну из тех ошибок, связанных с обратной совместимостью — лучше этого избежать. Я трижды откатывался на прежнюю версию, прежде чем окончательно забросить попытки мигрировать в середине проекта на пропатченый Екст. И теперь жалею, что вообще пытался. Если перефразировать Кнута: корень всех бед в миграции без веских причин.
Ничто не мешает использовать scope в конфигурации, если вам дополнительная гибкость не нужна. Дело в том, что createDelegate позволяет передавать в функцию дополнительные аргументы (это его огромнейшее преимущество).
Как раз на борьбу с зависимостями первая статья и делает упор. Погодите делать выводы сейчас, пожалуйста. Возможно, вы поменяете своё мнение, когда увидите картину в целом (после окончания второй статьи).
Я сделаю более подробную вторую статью, но она не раскроет больше по тем топикам, по которым я прошёлся в первой. В этой статье фасадом является Layout.base, так как он достаточно точно следует определённому в вики термину. Но полемику по этому вопросу я здесь разводить не хотел бы.
Простите, мне придётся с вами не согласиться. АПИ поможет реализовать, но не построить. В документации по апи нет ни слова о том, как начать писать приложение. Так что верным было бы всё же начать с туториалов.
К концу статьи мне бы хотелось, чтоб у читателя сложился каркас. Каркас — это вполне конкретная штука. Это то, с чего всё начинается. А детали реализации — это всего лишь детали.
Мне посоветовали не слать большую статью, а разбить её на небольшие, так как большие порции информации не всегда легко «глотаются». Видимо, это был хороший совет, раз вами кусок был проглочен за глоток кофе.
Я в заголовке написал о целевой аудитории. Эти люди уже должны были ознакомиться с предоставленными вами ссылками. Либо же у них были причины, по которым они не смогли с ними ознакомиться. Мой же цикл — не пересказ англоязычных статей, а попытка донести уникальный материал. Тот, которого пока ещё нигде нет. Думаю, вы сами сможете в этом убедиться во второй части статьи.
Касательно привязки привязки к версии — у нас всего лишь был разный опыт «общения» с фреймворком. У меня при апдейтах из репозитория, равно как и при официальном апдейте с 3.0.0 на 3.0.1 лезли пренеприятнейшие, непонятные ошибки. А я недокументированных возможностей, помимо конфигураций графиков, нигде не использовал (графики слабо документированы, приходилось смотреть их исходные коды). Таким образом, если есть даже малейший шанс заполучить хотя бы одну из тех ошибок, связанных с обратной совместимостью — лучше этого избежать. Я трижды откатывался на прежнюю версию, прежде чем окончательно забросить попытки мигрировать в середине проекта на пропатченый Екст. И теперь жалею, что вообще пытался. Если перефразировать Кнута: корень всех бед в миграции без веских причин.
И спасибо за ваш вердикт касательно статьи :)