Наверх ▲

Эффективная разработка веб-интерфейсов с Ample SDK

Сергей Ильинский Сергей Ильинский Cоздатель Backbase Ajax Framework и Ample SDK.

Сергей Ильинский: Я собираюсь представить свой сторонний проект, который я делаю свободное от работы время, не в рамках своей деятельности в компании. Уверен, что такого рода проекты интересуют многих разработчиков.

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

Существет огромное количество приложений и JavaScript-библиотек, которые могут пригодиться при построении клиентских веб-интерфейсов. Я разделяю их все на три группы. Первая — это библиотеки, второе — это пост-библиотеки/пре-фреймворки, третья — собственно фреймворки.

Почему я так делаю?
а) У них совершенно разная направленность, хотя используются они часто более широко.
б) У них разные возможности.

Библиотека, как правило, применяется для манипулирования кроссбраузерной моделью DOM (Document Object Model). Пост-библиотеки могут быть использованы как средства для создания приложений, хоть и не всегда очень эффективно. Я думаю, что многие из них вам знакомы.

Есть категория фреймворков. Как правило, это что-то более серьезное и стабильное. Это то, что специально создано и хорошо работает именно для построения клиентских интерфейсов.

У большинства существующих решений, которые помогают строить интерфейсы, имеется следующий набор проблем.

Каждый из них имеет проприетарный интерфейс программирования приложений (API). Например, если команда, занимающаяся Jquery, придумает какой-либо метод, в другой библиотеке его уже не будет. Что это значит? При попытке перейти с одной библиотеки на другую процесс станет трудоемким. Как мы перейдем с Prototype на Jquery, например?

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

Есть еще один не лчень критичный, но неприятный момент, о котором можно говорить применительно ко всем библиотекам. «Спагетти-код» при использовании обычных библиотек, как правило, нередкое явление. Получаются программы с плохой структурой. Постараюсь показать, как это можно оптимизировать. 

Фреймворк нужен не всегда. Назову несколько факторов, которые указывают на необходимость выбора именно фреймворка. Это решение, которое немного тяжелее, но гораздо эффективнее.

Если вы строите интерфейс приложения, в котором много одинаковых компонентов взаимодействия с пользователем, возникает необходимость писать эти компоненты. Просто написать компоненты, как это делается, например, в Jquery или UI, может быть недостаточно (особенно если речь идет о большом интерфейсе). Они зачастую работают независимо. Такой концепт, как вложенность одного компонента в другой, может не очень красиво выглядеть. Я покажу, как это может делаться по-другому.

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

Ample SDK — кроссбраузерная библиотека для построения пользовательских интерфейсов именно на клиенте, а не на сервере. Эта ее особенность позволяет создавать клиентские приложения, которые "общаются" с сервером только на уровне данных.

Архитектура этого фреймворка заключает в себе два принципиальных компонента. Первый из них — ядро, которое содержит реализацию объектной модели документа (не той, которая имеется в браузере, а своей, написанной на JavaScript).

Также в Ample SDK присутствуют агенты-менеджеры, управляющие пользовательским интерфейсом, генерирующие из простых событий (mouse_ click, mouse_over) более сложные (drag, start, drag-and-drop и так далее), и механизмы расширения платформы.

Отдельно от ядра реализовано нескольких языков разметки, о которых я подробнее расскажу чуть позже.

Модель программирования при использовании этого фрейворка целиком и полностью повторяет веб-браузер. Может быть, кто-нибудь слышал такое имя — Ben Galbraith (Бен Гэлбрайт)? Это один из евангелистов Ajax. Когда он увидел это решение, он назвал его «браузером в браузере».

Почему? Этот фреймворк, по сути, представляет собой реализацию браузера на JavaScript. Что это значит? Это весьма своеобразная реализация аспекта пользовательского интерфейса. Он может обрабатывать XML-документы (в простейшем случае это HTML-документ). Фреймворк Ample SDK может применять CSS. Логика приложения в таком случае пишется на JavaScript.

Разметка интерфейса в приложениях, написанных с применением Ample SDK, выполняется на XML. Это очень удобно по нескольким причинам. Во-первых, таким образом мы отходим от языка программирования и фактически декларируем документы, которые впоследствии могут, например, использоваться и отрисовываться на сервере.

Поскольку технологии разметки интерфейса стандартные, те же самые документы могут быть повторно использованы в другом браузере в качестве нативных. Например, в случае с технологией XUL, которую мы скоро увидим.

"Островки" XML в HTML вставляются так, как показано на иллюстрации. Это просто сниппет, который найден в приложении. Здесь показан простой документ. Документ также может быть очень большим, и в документе может быть несколько таких сниппетов. Также можно рассмотреть случай с приложением SPI (по архитектуре SPI — Single Page Interface), когда весь документ содержит только приложения.

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

На данный момент можно наблюдать реализацию нескольких технологий, которые изначально не присутствуют в браузерах. Но HTML присутствует до некоторой степени. XUL, например, присутствует только в браузерах на движке Gecko. Во фреймворке он реализован так, что эта технология становится доступной для использования абсолютно в любом браузере.

SVG — технология, имеющаяся во всех браузерах, кроме Internet Explorer. Благодаря тому, что в Internet Explorer есть VML, SVG транслируется "за кулисами" от программиста VML. Программист всегда, даже в IE, видит документ как SVG-документ и совершает над ним некие действия с помощью стандартных API.

Сейчас я работаю над несколькими другими языками. Это новые элементы разметки HTML, включая Сanvas. Если вы знаете, существует библиотека ExtСanvas, которая делает это. Но для интенсивных операций с Сanvas существует путь оптимизации, который я собираюсь применить.

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

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

Стилизация интерфейсов в таких приложения выполняется на CSS. Что это значит? XML - это язык, который очень хорошо "дружит" как с CSS, так и с объектной моделью документа. Это некое технологически единое пространство.

Если в некоторых фреймворках стилизация компонентов осуществляется с помощью JavaScript или странных нотаций на собственном псевдо-языке, то в данном случае подойдет обычный CSS.

Что-то здесь может показаться необычным. На самом деле, это совершенно обычные конструкции из CSS3. Например, пространство имен. Для чего нужно определение пространства имен, приведенное на данной иллюстрации?

Например, в SVG технологии есть тег <а>. Такой же тег есть в технологии HTML. Чтобы в CSS указать, что данный стиль должен быть применен именно к SVG-элементу <а>, нужно сначала декларировать префикс, а затем указать его в селекторе.

Как и в случае с "островками" XML, здесь необходимо использовать main type, который предотвращает обработку данных "островков" браузером и оставляет ее для фреймворка.

Среди поддерживаемых CSS-технологий стоит отметить Namespaces (пространство имен, которое уже указано). Это необходимая технология. Некоторая часть технологии CSS3 UI позволяет стилизовать фрагменты компонентов. Например, у нас есть компонент "календарь для выбора дат" (англ. datepicker), в котором, как правило, присутствуют поле ввода и кнопка. С помощью данной конструкции можно стилизовать именно поле ввода.

Логика приложения в случаях, о которых я рассказываю, пишется на стандартном языке JavaScript. Обрабатывается она непосредственно браузером, а не через какой-то интерпретатор. При этом используется API объектной модели документа (не изначальный браузер, а тот, который реализован во фреймворке).

Логика стандартная. В Internet Explorer при кодировании HTML-приложения всегда приходится делать разводки либо указывать «присутствует такой метод — тогда мы вызовем его, не присутствует такой метод — тогда мы вызовем другой». В данном случае технология объектной модели документа становится одинаково доступна во всех браузерах. Это не уровень "ноль" (есть несколько уровней доступности технологии DOM, в IE это "ноль"), а "два" или "три" во всех браузерах на уровне . "Два" означает, что технология полностью реализована, а "три" указывает на то, что она реализована частично.

Как я сказал, JavaScript, очевидно, будет обрабатываться браузером нативно. Например, этот фрагмент кода может быть совершенно неожиданным, но он работает одинаково хорошо во всех браузерах. Присутствует qyerySelector. Даже в Internet Explorer 5.5 все будет работать.

Браузер обнаруживает SVG-элемент. Я думаю, для программистов это совершенно очевидный код. Альтернативой документа объекта нативного браузера в приложениях, написанных с этим фреймворком, является объект ample. Это тоже объект с интерфейсом «документ». Он содержит в себе объектные модели всех фрагментов, которые найдены на странице, всех "островков" XML.

Среди технологий объектной модели документа (DOM), которые сейчас поддерживаются, не используется только одна — Expat. К сожалению, ее вытеснил Selectors API.

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

Менеджер Drag-and-drop реализован примерно так же, как ранее в IE, и как в HTML5, лишь с незначительными изменениями. Есть менеджер Resize, что позволяет изменять размер любых элементов.

Буквой «e» обозначены события, которые эти менеджеры вызывают, буквой «m» — методы. Это все одинаково работает с Internet Explorer 5.5.

Наверняка кому-то знаком и такой модуль, как Capture. 

Среди других API имеется XMLHttpRequest, который нативно не присутствует в Internet Explorer. Здесь он виртуализирован. Разработчик приложений может совершенно свободно его использовать, как будто он там есть. Все другие объекты, которые отсутствуют в Internet Explorer, а здесь реализованы, будут опираться на механизмы реализации соответствующих объектов в браузере Internet Explorer.

Также в рассматриваемом фреймворке имеется XML API. Это значит, что в "островках" XML можно использовать языки обработки, например, SMIL. Если кто вдруг не знает, то SMIL— это декларативная технология для описания анимаций.

Если при написании своего приложения вы сталкиваетесь с тем, что компонентов недостаточно (например, требуется список с обязательными флажками в конкретном приложении), их можно создать самому. Технология описания компонентов для последующего использования в приложениях на JavaScript документирована. 

Вторая точка расширения — это создание новых менеджеров интерфейса. Например, требуется менеджер действий мыши. В каких-то приложениях это может быть необходимо. Если браузер изначально не поддерживает это, мы можем регистрировать примитивные события и транслировать их в события более высокого уровня.

В конце я остановлюсь на нескольких вариантах ответа на вопрос о том, почему стоит посмотреть Ample SDK. Да, это тоже фреймворк для создания пользовательских интерфейсов, таких фреймворков несколько. Но данный фреймворк отличается от остальных тем, что не выдумывает никакой новой модели программирования (которую я ранее продемонстрировал).

Он содержит только стандартный API. Есть буквально пять или шесть свойств и нестандартных методов, но они все начинаются со значка доллара, поэтому их легко заметить. Их буквально пять или шесть.

Фреймворк предлагает достаточный уровень абстракции. Давайте представим то самое первое приложение. Там мы видели поля-вкладки, возможность предварительного просмотра, кнопки. Такие компоненты. При кодировании того же самого на HTML мы бы все время видели в нашем приложении какие-то штуки типа div и input-box.

Реализовав это как компоненты, можно использовать данные компоненты в XML и подняться на новый уровень абстракции. На нем уже неважно, как эти компоненты реализованы. Предположим, какой-то конкретный браузер реализует в какой-то момент XUL. Тогда это можно будет отдать на откуп этому браузеру рендеринг XUL-технологии, а в другом по-прежнему использовать реализацию на HTML.

В силу одной интересной особенности рендеринг интерфейса в данном фреймворке идет намного быстрее, чем в других. Здесь для отрисовки всего интерфейса используется только один вызов DOM API. Браузер нативный. Все компоненты в конечном итоге будут преобразованы в какую-то технологию, которая поддерживается браузером. Например, SVG преобразуется в VML или XUL, в конечном итоге идет рендеринг в HTML в качестве теневого контента.

Это проект Open Source. Им пользуются коммерческие компании. Они находят это эффективным.
 
Теперь я бы хотел услышать какие-нибудь вопросы.
Вопросы и ответы
Вопрос:
— Скажите, чем это все принципиально отличается от Dodgy Digit? Там примерно такая же концепция: мы в обычный HTML подмешиваем теги специального вида, вешаем handler и так далее.
Сергей Ильинский:
— Насколько я знаю, Dodgy использует HTML для декларации интерфейсов. В этом HTML нужно указывать классы. Код, который вы видите, преобразуется во что-то другое. Объектная модель, с помощью которой вы будете получать доступ, это объектная модель документа браузера.
Если вам нужно получить, например, список наименований в этом компоненте, вы будете искать какие-то div’ы и так далее. Здесь вы сделаете qyerySelector, list-box. На ней вы можете выполнять DOM-операции. Установить какой-то атрибут, подсветить его, сделать, чтобы он был выбран.
Вопрос:
— Если рассматривать XUL-реализацию, насколько она адаптируема к разным темам? То, что называется theme.
Сергей Ильинский:
— Если бы был Интернет, я бы показал. Фрагмент CSS-документа был показан ранее. Можно сделать. Единственное ограничение — не все можно сделать CSS в конечном итоге. В связи с этим в каких-то случаях необходимо менять разметку теневого контента. Это будет ограничением.
Что такое «теневой контент»? Если кто-то знает технологии XBL или HTC Internet Explorer, то теневой контент — это то, что разработчику приложения не видно. Данный компонент отрисовывается в конечном итоге в HTML, но разработчик приложения, использующий этот компонент, будет общаться с ним на том уровне, на котором у него существуют такие сущности, как list-item, list-box, но никак не какие-то из того самого теневого контента, в который рендерятся div’ы, флажки и так далее. Что-то понятно?
Вопрос:
— Здесь идет отрисовка в HTML. Как на это будут реагировать такие инструменты, как Firebug, который все повсеместно используют? 
Сергей Ильинский:
— Поскольку данное средство создано для того, чтобы отображать HTML, вы в нем увидите HTML. Абсолютно все, что там внутри.
Как бы оно безобразно, сложно и так далее ни было. Есть проект: человек занимается созданием плагина для Firebug, который будет отображать именно объектную модель этого документа.
Вы можете самостоятельно программными средствами осуществлять навигацию по этому документу... Можно написать на JavaScript этот же самый инструмент. Вы понимаете?
Вопрос:
— Подскажите, какие условия лицензирования данного фреймворка?
Сергей Ильинский:
— MIT. Берите — пользуйтесь, продавайте. Я это делаю ночами. Нет, не продаю. Разрабатываю.
Вопрос:
— Вы говорили, что данный фреймворк уже использовался в реальных проектах?
Сергей Ильинский:
— Да.
Вопрос:
— Какой сложности интерфейсы на нем были реализованы? Интересует количество элементов управления на форму, количество записей в скроллере и количество колонок в таблице.
Сергей Ильинский:
— Здесь два вопроса. По счастливой случайности, его использует мой работодатель, который купил лицензию в то время, когда этот фреймворк еще не относился к Open Source. Он пишет на нем приложения, несколько приложений. Это одна из пяти ведущих компаний в области Интернет-аналитики. Мало кто слышал, наверное, но в Европе она имеет рынок.
Они разрабатывают интерфейсы для веб-аналитики, подобно Google Analytics. Я думаю, что в подобном интерфейсе может присутствовать где-то 500-600 элементов, но это, естественно, не предел.
Теперь по второй части вопроса. Человек имеет такую особенность, которая ограничена еще и браузером, - он способен объять только объятное.
Вопрос:
— Но хотеть невозможного.
Сергей Ильинский:
— При попытке отрисовать двадцать тысяч строк в таком компоненте браузер повиснет. Этого делать не надо. Можно "за кулисами" (компонент не оптимизирован, но его можно оптимизировать) сделать так, что он будет отрисовывать только то, что видимо. В таком случае их останется всего 10.
Вопрос:
— Пробовали ли вы на базе подобного фреймворка делать приложения, которые работают какое-то время автономно от сервера? Что вы использовали для хранения данных на клиенте?
Сергей Ильинский:
— Автономно от сервера? Что вы имеете в виду?
Вопрос:
— Типа Google Mail. Вы берете данные, с ними работаете, будучи отсоединенным от сервера. Через несколько часов присоединяетесь и обновляете.
Сергей Ильинский:
— Одна из компаний, которые используют этот фреймворк (уже упомянутая) имеет интерфейсы такого типа. Это Single Page Interface, кода весь интерфейс загружается или загружается частями по мере необходимости. Его жизненный цикл не прерывается на протяжении нескольких часов. В смысле утечек памяти и так далее это все идеально отрихтовано. Нет проблем.
Достаточно интересно, что в одном приложении данной компании благодаря использованию этого фреймворка front-end сервер целиком оказался разгружен от каких-либо задач по формированию пользовательского интерфейса.
Это все статичные файлы, которые лежат на сервере. Они получаются по необходимости. В зависимости от каких-то условий данных (скрываются или открываются какие-то фрагменты) они в данной компании общаются с сервером на JSON. Front-end преобразует эти JSON-запросы в sob-запросы к back-end. Таким образом это работает.
Вопрос:
— Собираетесь ли вы делать визуальную схему для конструирования различных компонентов, форм?
Сергей Ильинский:
— Я думаю, что вы спрашиваете о конечном приложении. Я не занимаюсь построением приложений. Более того, мне это глубоко неинтересно. Мне интересно создание мета-средств. Средств разработки. Да, это может быть приложение. Оно может быть написано. Есть одна компания, которая сейчас делает визуальный конструктор для создания интерфейса менеджерами.
Вопрос:
— Где-то в скринах вы указали, что есть возможность использования в дальнейшем XForms построения.
Сергей Ильинский:
— Да. Технология может быть реализована.
Вопрос:
— Я думал, что в дальнейшем есть возможность, что вы реализуете какой-то визуальный конструктор, как вы говорите, чтобы можно было строить компоненты, выбирая их из какого-то набора и настраивать. Автоматически будут настраиваться также все действия, связанные с этими компонентами, и XML.
Сергей Ильинский:
— Про действия — есть Visual Studio: все визуально делать, если вы верите. Конечно, визуально ничего не делается. Ни в одном реальном приложении ничего визуально сделать нельзя. Приложение визуально написать невозможно. Именно поэтому то, о чем я рассказывал, это только аспект пользовательского интерфейса.
Вопрос:
— Есть ли какое-то решение для индексирования контента, который пишется с использованием мета-языка разметки? Например, для поисковых систем.
Сергей Ильинский:
— Совершенно правильный вопрос, который имеет две стороны. На часть вопроса можно ответить таким образом: здесь имеется не один способ, с помощью которого эти фрагменты можно вставить в HTML-документ. Если посмотрите на сайте, то есть другой синтаксис, с помощью которого сам контент XML остается в области видимости HTML-документа, а не внутри скрипт-тега. Контент скрипт-тега не индексируется.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Денис Бесков

Денис Бесков

Тренер, консультант, организатор "With a Little Help from My Friends".

Будут рассмотрены четыре производственных контекста подробно: что это такое, как они устроены, как в них работают люди, чем они характеризуются.

Эсен Сагынов (Esen Sagynov)

Эсен Сагынов (Esen Sagynov)

Разработчик в NHN - крупнейшей IT-компании Южной Кореи.

Мы будем говорить о CUBRID и расскажем, как мы разработали эту платформу, зачем мы ее разработали, почему мы не пользовались уже существующими решениям.

Джош Беркус (Josh Berkus)

Джош Беркус (Josh Berkus)

Член команды PostgreSQL, специалист по БД.

Несерьезная техническая презентация Джоша Беркуса о реляционных и нереляционных базах данных.