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

[murr]

Замечательный фреймворк, однако достаточно громоздкий, в плане написания и поддержки кода. На работе мы обсуждали плюсы и минусы такого подхода, и пришли к выводу, что будем использовать 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 на Хабре.

[Kupyc]

Хм. Или примерное приведение мешает понять смысл или... мы пишем лишний код? Можно ведь, как говорилось выше, описать преднастроенный класс и получить готовый сложный контрол. Причем эта операция попутно решит проблемы сокрытия тонкостей. Если контрол многокомпонентный, то поможет создание контейнера с написанием кода межкомпонентного общения т.е. мы бесплатно получаем высокоуровневое API контрола.

А я все правильно понял? :)

[Yeah]

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

[Kupyc]

"Мопед не мой...". Шучу. Я не являюсь автором текста, ведь это перевод. Впрочем, это мало что меняет - по сути вопроса я тоже мало что могу сказать т.к. указанные Вами техники не использовал. Вам лучше поинтересоваться на их счет в ru-extjs гугл-группе, а конкретно у Александра Лозовюка потому как он как как-то поднимал уже эту тему.

[Yeah]

Да, я подписан на эту группу. Есть, кстати, отдельная Гуглогруппа связанная непосредственнос PHP_Ext. Меня интересовал Ваш личный опыт и Ваши впечатления. Я сам ковырял эту библиотеку, расширял ее, чтобы сделать совместимой с последними версиями Ext. Но вот мнение у меня осталось двойственное. С одной стороны удобно, но с другой стороны проще написать на чистом JS.

[Kupyc]

Ух ты! "С одной стороны удобно, но с другой стороны проще написать на чистом JS" - это именно то, что я сказал себе, когда обозревал перспективы этой техники. Еще я опасался того, что в ExtJS и так море нюансов, а навешивать дополнительный слой абстракции - только множить их.

[djem]

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

[mente]

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

[4orever]

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

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

[npFly]

Ну обчно Ext используетса где то на backend, а на backend как говоритса можно и потерпеть.

[Kupyc]

С производительностью, увы, наблюдаются некоторые проблемы. Дело в том, что движок генерирует довольно сложный html-код и чем больше элементов интерфейса на странице тем заметнее тормоза. Причем (субъективно и непроверено), если страница уже имеет свой собственный код, т.е., например, является частью существующего сайта, то довольно сильные тормоза проявятся в момент загрузки и инициализации ExtJS. Я зарекся внедрять ExtJS в страницы, однажды создав красивый псевдомессенджер аля QIP - каждая страница после загрузки еще 2-3 секунды не давала себя кликнуть.
Что касается подгружаемого кода, то обычно это около 600 килобайт кода самого фреймворка + его ресурсы. Затем, при условии кеширования, от канала не требуется высокой пропускной способности.

[4orever]

Из вашего комментария я делаю вывод, что сложные интерфейсы на его основе для обычных пользователей лучше не проектировать. А если с его помощью несколько расширить функционал обычных форм? На вскидку, как скажется на производительности клиента добавление < 10 элеентов, которых не достает в обычном HTML (ползунки там всякие и прочие элементы управления?). Я так подозреваю, что основные тормоза начинаются при использовании таблиц немалого размера + сортировка в столбцах.

[Kupyc]

А когда интерфейс становится сложным? ;) Наверное, Вам лучше поглядеть все это в деле, у производителя отличные демки.

Что касается расширения обычных форм, то хотелось бы заметить, что неслучайно и в статье, и применительно к проектам ExtJS употребляется слово appliccation. Т.е. в случае с этим фреймворком ведется разработка не сайта, а приложения, а у них и логика разная, и назначение, и устройство. Расширять стандартное, имхо, лучше с помощью менее монолитных систем, того же jQuery и большого числа его плагинов. Хоть в последнее время и появилась возможность изменять цветовую гамму тем ExtJS, но в большинстве случаев этого недостаточно и отдельные вставки контролов выглядят в обычной форме довольно нелепо.

Про большие гриды Вы правы, да. Еще тормоза замечаются при организации большого числа (порядка 20) окон и их свертывание-развертывание выглядит довольно уныло. Кстати, относительно недавно была очень познавательная статья по оптимизации грида.

[sergonavt]

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

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

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

[Kupyc]

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

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

[Kupyc]

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

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

[VasilioRuzanni]

Чтобы удостовериться в том, что каждый компонент делает все правильно, мы используем средства автоматизированного функционального тестирования интерфейсов, например Selenium. Очень советую!