Создание сложных приложений в ExtJS.

Замечательный фреймворк, однако достаточно громоздкий, в плане написания и поддержки кода. На работе мы обсуждали плюсы и минусы такого подхода, и пришли к выводу, что будем использовать Ext, но для него напишем высокоуровневую обертку, которая скроет от рядового программиста большинство тонкостей. Для тех, кому вдруг понадобится функционал чистого ExtJS, предусмотрена возможность это сделать.

Примерно, эта концепция выглядит так:

 

function createSomeFormPanel() {



    // наша обертка для Ext.FormPanel

    var form = new SomeFormPanel();



    // пара обычных полей

    var text1 = Fields.createTextField("name1", "caption1", "value1");

    var text2 = Fields.createTextField("name2", "caption2", "value2");



    // условный валидатор на первое поле

    var validator1 = function (value) {



        if (value != "value1") {

            return "Error";

        }

    }

    

    // добавляем к форме текстовые поля

    form.addInRight(text1, validator1);

    form.addInLeft(text2);



    // возвращаем обьект формы

    return form.create();

}

а уж за назначение валидаторов, вывод ошибок, внешний вид контролов и т.д. отвечает наша обертка.

А вообще, наверное, можно блог создать отдельно по ExtJS на Хабре.

Фреймворк мне очень понравился, но я к своему стыду до недавнего времени писал в точности в соответствии с рекомендацией "как не надо". Потом заглянул в примеры и понял "как надо".
Вопрос к автору: что скажешь по поводу библиотек по генерации года ExtJS (PHP-Ext и ExtPHP)???

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

Хорошая идея :). Юзаю ее уже давно, только в MVC архитектуре. Молодцы что написали.

Спасибо за комментарий. Давно искал подобный фреймворк для создания удобных интерфейсов. Выглядит весьма привлекательно и функционально. Будем разбираться и плотнее осваивать JS.

Кстати, а что там с производительностью? Как себя будет чувствовать бухгалтер за стареньким пентиумом и небыстрым каналом связи? Много ли кода подгружается в среднестатистических приложениях?

Мы для себя решили проблему межкомпонентного общения с помощью библиотеки OpenAjax (на самом деле, подойдёт любая библиотека, позволяющая подписываться на события и публиковать их). Компонент A публикует событие "ru.habrahabr.sergonavt.list.selected" и передаёт связанные с этим данные (например, id элемента списка, текст элемента списка). Компонент B подписан на это событие и создаёт закладки.
В любой момент мы можем добавить компонент C, который подпишется на это событие и будет, к примеру, подгружать раздел контекстной справки для выбранного элемента — на коде и работоспособности A и B это никак не скажется.

Если мы уберём со страницы B и C — A от этого работать не перестанет.

Если мы уберём со страницы A — ну, B и C перестанут получать эти события. Если никаких других источников события нет и эти компоненты не реагируют аналогичным образом на другие события — B и C перестанут открывать и подгружать (а вы думали, что в сказку попали? :) ). Но никаких ошибок javascript при этом тоже не будет.

Мне видится, что это не совсем правильно, без уточнения степени связанности компонент. Паттерн Observer (public/subscribe), опять-таки имхо, больше подходит для слабосвязанных компонент, когда подписка на событие носит практически необязательный характер. Если нет ошибок JS - это прекрасно, однако ведь не одно это является целью, верно? Необходимо обеспечить отсутствие ошибок в логике, а присутствующий в программе компонент, который ничего не делает или делает, но "в пустоту" - это как раз ошибка логики.

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