При тестировании YUI-компонента TreeView в Internet Explorer выявилась серьезные проблемы со скоростью рендеринга при более, чем 100 узлах в одной ветке. Скорость отрисовки узлов просто неприемлема. Пошурудив на форуме разработчкиков, мы обнаружили, что эта проблема уже заявлена, но как-то не нашла пока достаточного отклика со стороны команды YUI.

Самое обидное, что компонент показывает отличные результаты по рендерингу в др. браузерах (FF и Opera), и только долбанный IE, сука, отрисовывает 100 узлов так, как будто он трехмерную модель их в памяти строит.

Надеемся, что в команде YUI все-таки решат эту проблему. Мне слабо верится, что наш extremus, который написал дерево для первой версии XS2 и который как-то эту проблему обошел/решил, намного круче яхуйных индусов.

Пока индусы думают, мы решил срочно заменить их дерево деревом extremusа. Оно более чем функционально и прекрасно себя зарекомендовало. Единственный его недостаток, что оно не компонент YUI. Однако YUI сам виноват...

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

Представим обычный интернет-магазин с большим количеством разнородных товаров. Для каждого типа товара мы заведем свой тип узлов со своим набором полей. Однако, такие поля как "Цена", "Количество на складе", "Производитель" и т.п. совершенно точно будут присутствовать у всех товаров. Конечно, можно просто во всех типах завести соответствующие поля с одинаковыми названиями - обычно разработчики так и поступают. Но представьте, насколько благостнее было бы создать тип "Товар", куда собрать все общие для всех товаров поля, а затем наследовать от него все типы товаров! При этом можно было бы, скажем, при выборках с помощью функций API указывать в параметре NType название самого абстрактного типа "Товары", а при этом система выбирала бы узлы всех типов, которые от него пронаследованы. При указаниее ссылок lnk наследование бы тоже срабатывало. Если для какого-то поля указано, что оно является ссылочным и допускает указание узлов типа "Товар", это означает, что в него можно указать любой из типов-наследников "Товара". Более того, методы, как в нормальном ООП, тоже можно было бы наследовать. Можно написать метод "show", который навесить на абстрактный "Товар". Однако вызывать его можно будет на любом из типов-наследников. Конечно, метод в этом случае должен быть полиморфным.

Вот такая концепция.

Насколько же отличался инет в 2005 от того, что он есть сейчас. Помню, что именно тогда завел себе аккаунт гмаила и мы вместе с Ясиком [ой, вырвалося]→охуевали от аяксового интерфейса. Теперь это, кажется, один из самых древних представителей такого интерфейса. Про ютуб мы тогда еще не слышали, про "веб 2.0", насколько помню, тоже. PHP5 еще еле-еле выползал из сырой стадии, Unicode считался в рунете бесполезной тратой времени. Джаваскрипт все еще многими считался скриптом... CMS читалось как "КМС". "Битрикс" уже сосал. А конторка была стартапом.

Время - это круто.

Онлайн-версия доступна тут - http://www.solutecs.com/library/chapter/show/ru.htm.

Сейчас pdf-версия по содержанию полностью соответствует онлайн-версии. Однако, думаю, что ее нужно дополнить приложением с XS2 API, онлайн версия которого находится здесь - http://www.solutecs.com/online/index/ru.htm.

В ближайшем будущем вся документация XS2 будет переведена в формат онлайн/pdf. Полный пакет документации будет состоять из:

1. XS2 Быстрый старт (XS2 Quick Start)
2. Руководство разработчика XS2
3. Руководство пользователя XS2 (это то, что сейчас называется XS2 Manual)
4. Справочник XS2 API

Тогда было принято решение включить эти функции в API, поскольку, казалось, они могли бы использоваться не только для листалок, но и просто для работы с диапазонами узлов в выборке. Однако дальнейший опыт разработки показал, что включение их в API было ошибочным. Они использовались только для листалок, а это частное применение, которое хорошо бы было реализовать просто в виде модуля на подобие модулей "Многоязычность" или "AJAX".

Вторая проблема этих функций состоит в том, что для их работы требуется выборка всех узлов. Это означает, что для вывода одной страницы, на которой показываются только 10 товаров из 1000, нужно выбрать всю 1000. Конечно, есть пути оптимизации: например, можно делать выборку только идентификаторов, а затем, когда произведена вырезка диапазона, выбрать полностью все поля только для узлов данного диапазона. Но все равно... некошерно, [ой, вырвалося]→бля.

Во второй версии мы решили сделать эти функции нерекомендуемыми для использования, и перенести их в общий модуль "Постраничный вывод". Кроме того, во второй версии в функции выборок решено добавить помимо параметра limit еще и параметр offset, задающий начальную позицию диапазона выборки. В паре эти два параметра позволяют не выбирать всю тысячу узлов для вывода 10 из них.

Для вывода "листалок" нужно знать, сколько узлов всего в выборке. Сейчас эту задачу можно решить только путем тупого подсчета количества возвращенных узлов с помощью функции count.  Это, конечно, полное [ой, вырвалося]→уебанство и нарушение "благостной гармонии" (©Ху Цзин Тао, 2007). Для оптимального посчета количества узлов в выборке во второй версии появится функция xs2CountNodes, которая будет возвращать количество узлов, удовлетворяющих условию, заданном в ее параметере condition.

Проблема выявилась, как всегда, неожидано. Во второй версии XS2, как я уже говорил в одном из первых постов, все описывается через узлы. В том числе и сам тип "узел" описан с помощью узлов. Для описания узла в XS2v2 существует два типа: ntype и field. Они описывают тип "узел" и его поля соответственно. При этом узлы типа field вкладываются в узлы типа ntype.

Все было заебись, пока мы не добрались до места в интерфейсе, где пользователь может изменить псевдоним для полей NName (Название), NodId (Идентификатор) и NFlag (Флаг видимости). Мы поняли, что этот псевдоним просто негде сохранить, поскольку наш тип field предназначен для хранения информации о специфических полях узла, а не общих.

После недолгих споров мы решили просто добавить еще один тип cfield, который также вкладывается в ntype и очень похож на field, однако, в отличие от field, хранит информацию об общих полях. Почему нельзя было описывать системные поля тем же типом, что и несистемные? Прежде всего потому, что разработчик, получающий информацию о типе, должен легко отсеивать одни поля от других. Чтоб было понятно, о чем вся эта шняга, приведу пример:

{*выбираем из администраторского проекта узел, описывающий тип "Новость"*}
{xs2GetNodes prj="adm" mod="projects" condition="NName='news'" NType="ntype" var="news_ntype"}
{*выбираем все специфические поля типа "Новость".*}
{xs2GetChildren prj="adm" ParId=$news_ntype[0].NodId NType="field" var="fields"}
Список специфических полей типа "Новость":

{foreach from=$fields item="field"}
      {$field.NName} ({$field.Alias})
{/foreach}
{*а теперь выбираем системные поля NName,NodId,NFlag*}
{xs2GetChildren prj="adm"  ParId=$news_ntype[0].NodId NType="cfield" var="fields"}
Список системных полей типа "Новость":
{foreach from=$fields item="field"}
      {$field.NName} ({$field.Alias})
{/foreach}

По-моему, получилось прикольно. 

P.S. Бля, тока как все это объяснять будем...
 

Суть баги заключается в том, что в определенных случаях в поле типа lnk некоторые ссылки не сохроняются. Однако, мы пришли к выводу, что ни один проект на XS2 не столкнулся с этой проблемой потому, что условия ее возникновения слишком редки:

1. В типе должно быть поле, в котором можно указывать несколько узлов
2. Узлы должны быть не только разного типа, но и из разных модулей
3. Эти узлы из разных модулей должны иметь одинаковый идентификатор и должны встретиться в одном линковом поле.

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

По задумке мануал будет состоять из трех частей.
Первая часть уже почти готова и содержит разжеванные до семантической каши подробные указания, как сделать модуль, тип, как работать с шаблонами и процессорами, как производить выборки и вставки и т.п. Вот небольшой кусочек из первой главы первой части, в которой производится вправка мозга:

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

Для того, чтобы сделать сайт на XS2, прежде всего необходимо как раз описать его в принятых на данной платформе терминах. Основным элементом модели данных в XS2 является узел. Вместо того, чтобы пытаться дать отвлеченное определения этого понятия, приведем несколько примеров объектов, которые могут быть представлены в XS2 в виде узла: новость, статья, блог, запись в блоге, пользователь, объект недвижимости, товар, заказ, строка заказа, фотография, пункт в меню сайта. Эти узлы имеют определенное поведение, которое определяется как общими для всех узлов свойствами, так и свойствами, придуманными разработчиком сайта. Общие для всех узлов в XS2 являют такие свойства, как идентификатор узла, его название, дата создания и проч. Для всех узлов в качестве их стандартного поведения в XS2 реализованы следующие операции: вкладывание узлов друг в друга в виде дерева, добавление, редактирование, удаление, перемещение и копирование узлов. Кроме того, узлы могут содержать произвольные ссылки друг на друга. Например, узел "Новость" может ссылаться на узел "Автор", узел "Строка заказа" явно должен содержать ссылку на товар, узел "Заказ" ссылается на узел "Покупатель" и т.п. Очень важно понимать, что XS2 изначально не содержит готовых объектов – вы придумываете и создаете их сами, указывая их свойства и ссылки между ними."

Вторая часть будет содержать также рекомендации, но уже не для начинающих, а для продвинутых. Думаю, там будут разобранные примеры решения реальных нетривиальных задач. Например, организации тэгов, мультиязычность, синхронизация двух проектов, взаимодействие с web2.0-сервисами, взаимодействия с Flash 

Треться часть будет справочником. Туда войду описание API, представленное сейчас вот здесь - http://www.solutecs.com/online/index/ru.htm. 

При архивации проекта целиком (не отдельных модулей), особых проблем не возникает. Здесь существует два основных варианта: перенос структуры+данных, перенос только структуры. Первый вариант очевиден, второй - очевиден более менее. При переносе только структуры в проекте, куда производится перенос, все данные изменяются так, чтобы соответствовать новой структуре: например, если удалилось поле типа, то удаляются и данные этого поля; если изменился тип поля, то произойдет приведение данных этого поля и т.д.

Гораздо большую сложность представляет собой перенос отдельных модулей. Основная проблема - это связи между модулями, проявляющиеся в наличии полей типа lnk в объектах. Например, мы архивируем модуль "Блог", в котором есть тип объекта "Дневник" и в этом типе есть поле "Пользователь", содержащее ссылка на объект "Пользователь" из модуля "Пользователи". Допустим, мы архивировали отдельно модуль "Блог" - в архиве будут содержаться половинчатые ссылки на пользователей. Теперь мы разархивируем архив на другом проекте, где модуль "Пользователи" тоже есть. Понятно, что процедура разархивирования должна постараться на основании тех данных о ссылках, которые есть в архиве, восстановить ссылки Журнал->Пользователь.

Для восстановления целостности ссылок при переносе архивов необходимо заново разработать два надежных механизма:

1. Механизм идентификации одного и той же сущности на разных проектах. Процедура разархивации должна установить, что модуль "Пользователи", с которым связан разархивирумый модуль "Блог", - это тот же модуль "Пользователи", который был в исходном проекте.
2. Механизм идентификации одной и того же объекта на разных проектах. Даже если модули на проекте-источнике и проекте-приемнике одинаковы, никто не гарантирует, что дневник под номером 2 на одном проекте и дневник с таким же номером на втором - это один и тот же дневник.

Первый механизм будет реализован на базе GUIDов. Многие скажут, что и со вторым следует поступить так же. Но здесь есть много НО, и мы еще точно не решили, какое решение здесь применим.

"В Канбалу [Ханбалык] монетный двор великого хана, да такой, что про  великого хана сказать можно -- алхимию он знает вполне, и вот почему. Приказывает он изготовлять вот какие деньги: заставит он набрать коры от тутовых деревьев, листья которых едят шелковичные черви, да нежное дерево, что между корой и сердцевиной, и из этого нежного дерева приказывает изготовить папку, словно как бумагу; а когда папка готова, приказывает он из нее нарезать вот как: сначала маленькие [кусочки], стоящие половину малого ливра, или малый ливр, иные ценой в пол серебряный грош, а другие в серебряный грош; есть и в два гроша, и в пять, и в десять, и в безант, и в три и так далее до десяти безантов; и ко всем папкам приложена печать великого хана. Изготовляется по его приказу такое множество этих денег, что все богатство в свете можно ими купить. Приготовят бумажки так, как я вам описал, и по приказу великого хана распространяют их по всем областям, царствам, землям, всюду, где он властвует, и никто не смеет, под страхом смерти, их не принимать. Все его подданные повсюду, скажу вам, охотно берут в уплату эти бумажки, потому что, куда они ни пойдут, за все они платят бумажками, за товары, за жемчуг, за драгоценные камни, за золото и за серебро: на бумажки все могут купить и за все ими уплачивать; бумажка стоит десять безантов, а не весит ни одного."

"Книга о разнообразии мира", Глава XCVI

Для того, чтобы отредактировать произвольный метод не используя при этом XS2 Client (он ставится только на Windows), нужно кликнуть на проекте, модуле или типе объектов, выбрать пункт "Методы", затем выбрать метод, щелкнуть по нему, выбрать пункт "Скачать", выбрать, что именно скачать: шаблон или процессор, затем в открывшемся браузерном окне выбрать папку на локальном диске, куда скачать, затем открыть программу-редактор, открыть в нем сохраненный файл, отредактировать, сохранить, вернуться в интерфейс XS2, выбрать пункт "Заменить", в открывшемся окне выбрать на локальном диске измененный файл, нажать кнопку "Сохранить". Ну вообщем только закаленный бессоными ночами борьбы с линуксовыми конфигами админ не разразился бы при этом лишенной эвфемизмов тирадой.

Теперь редактировать код метода можно прямо в браузере. В меню работы с методом добавился пункт "Редактировать" при нажатии на который открывается окошко с кодом метода. Это стало возможно благодаря охуительной технологии Codepress, позволяющей подсвечивать синтаксис прямо в браузере. Отдельная благодарность нашим партнерам из ФГУП ВНИИ «Агросистема», которые:

1. Вынесли нам все мозги не отставали от нас с просьбами сделать редактирование в браузере;
2. Рассказали нам про Codepress.

Фича выйдет в версии 1.31.3.

Прежде всего добавил возможность соединятся сервером по альтернативным портам, а не только по 80. Затем добавил выбор кодировки проекта (раньше была жестко задана win-1251). Добился-таки того, чтобы при обновлении клиента сохранялись все его настройки, включая аккаунты. И наконец, исправил надоедливый баг при создании ресурсов.

Много времени ушло на то, чтобы разобраться с технологией разворачивания приложения Microsoft ClickOnce. Клиент распространяется по этой технологии. Она действительно очень удобна, но у нее есть ряд подводных камней. Думается, что в ближайшее время нужно будет все-таки сделать версию с обычным инсталлятором.

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

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

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

Зачем было делать все³ из панелей? Причин сразу несколько:

1. так выглядит моднее,
2. а фреймы морально устарели
3. и, наконец, гибкая раскладка удобнее.

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

Дерево модуля (цифра 2 на картинке) — другой виджет, который постоянно используется в XS2. Это большой кусок кода, написание которого для первой версии заняло много времени, а доработка напильником — еще больше.

Чтобы не усугублять эффект второй системы⁴ мы решили взять готовую интерфейсную библиотеку и выбрали YUI.

YUI — это взрослый пакет, который развивается (и используется) в Yahoo! Они набрали в команду разработчиков таких звезд, что рыночные проблемы их вряд ли коснутся. Получилась мощная библиотека виджетов. Кроме упомянутых элементов в ней есть табы (цифра 3 на скриншоте), календарь и масса других полезностей.

И чем же этот Юй⁵ полезен покупателю XS2, разработчику? Во-первых, чем симпатичнее админка, тем приятнее будет показать ее своему заказчику ;) Во-вторых, Юй отлично документирован и с его помощью легко заточить проект под потребности клиента. Кроме того, можно использовать Юй и на фронтдоре,⁶ раз уж библиотека⁷ уже идет в комплекте с XS2.

¹ Большие скриншоты, как обычно, видны при клике на картинке.

² Хотел поставить ссылку, но не знаю куда. Павлик! Если ты это читаешь — подскажи ;)

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

⁴ См. пятую главу Брукса.

⁵ На самом деле он звучит, как [вай-йу-ай]. Увы, варварское произношение неблагозвучно.

⁶ То есть, на самом сайте.

⁷ В другой раз попробую на примерах осветить подробности использования этой замечательной библиотеки.

Наверняка многие разработчики, работающие на XS2, обратили внимание на избыточность этой функции. Она выбирает все объекты, у которых в любом или в каком-то конкретном поле есть ссылки на указанный объект. Так, например, следующая конструкция вернет все книги, у которых в поле Author стоит ссылка на объект с идентификатором 2:

{xs2GetLinks NodId=2 lnkField="Author" NType="book"}

Возникает справедливый вопрос: а почему нельзя просто для подобной задачи написать вот так:

{xs2GetNodes NType="book" condition="Author.NodId=2"}

Пару раз, помню, мне даже пришлось объяснять по телефону, почему так нельзя. "Ну вы знаете, для проверки данного условия придется отображать объектный запрос на реляционную БД, а это трудоемко и породит дополнительную нагрузку на сервер, а вы же потом и жаловаться на медленные запросы будете...". Объясненьице пиздец какое убедительное.

Вообщем, во второй версии так можно!

И даже более того - можно, например, вот так:

{xs2GetNodes NType="book,article" condition="Author.City.NName='Лондон' OR Author.Country.Language.Code='en'"}

т.е. запросить все книги и статьи, у которых автор живет в Лондоне, или у которых автор живет в стране, в которой говорят на языке с кодом 'en'. При этом дано:

1. автор и город - это отдельные объекты: автор содержит ссылку на город в поле City
2. автор также содержит поле Country, в котором можно указать объект "Страна", у которой в свою очередь есть поле Language, в котором можно указать объект "Язык", и у этого языка есть поле Code).

Для обратной совместимости в API второй версии функция xs2GetLinks останется, но она получит статус deprecated.

Рабочее название этой фичи — «кастомный node edit».

Попробую подобрать пример, когда может пригодиться эта штука. В одном из наших проектов есть модуль с парой типов в нем. Узлы первого типа описывают приказ (его дата, название, автор и все такое). Другой тип содержит пункты из текста приказа. Узлы с пунктами вкладываются в свои приказы.

На сайте все замечательно — на странице редактирования приказа есть кнопка «добавить пункт», которая динамически дорисовывает форму и т.д. А вот обозреть сразу все пункты в админке затруднительно. Разве что в табличном виде, но в нем возможен только просмотр, а исправлять текст можно только редактируя пункты по очереди.

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

1. запрашивал все дочерние узлы (пункты приказа) вызовом xs2GetChildren и
2. выводил их текст в редактируемых полях (например, в тегах textarea).

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

Самое приятное — то, что не нужно переделывать стандартную форму редактирования заново. Она просто включается перед (или после) списка с помощью обычного вызова xs2Fetch.

Осталось только зайти в описание типа "приказ" и выбрать созданный метод в качестве редактора. Подобным способом можно за полчаса

• упростить жизнь редактору,
• или просто настроить оформление под пожелания заказчика.

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

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

Что же такое самоописание?

Самый клевый пример самоописывающей системы я нашел у Лао Цзы!

 人法地, 地法天, 天法道, 道法自然
Человеку закон - Земля, Земле закон - Небо, Небу закон - Дао, для Дао [же] закон - сам [Дао].
Лао Цзы, "Дао дэ Цзин", глава 25.

Переложив этот принцип на XS2 мы получим: действительность описывается контентом, контент описывается объектами, объекты описываются самими объектами.  
Если этот принцип реализовать, то получится, что, например имея объект "Книга Джунглей" типа "Книга" мы бы имели другой объект, который бы описывал тип "Книгу". Этот объект (или группа объектов) описывал бы все поля объектов типа "Книга", содержал бы его методы и т.д. А если так, не было бы никакой разницы между работой с объектами, модулями, методами, полями, поскольку все бы они были объектами. Теми же функциями XS2 API можно было бы получить, например, список всех полей типа объекта "Книга", или скажем, получить все типы объектов, имеющиеся в модуле "Книги". Более того, можно было бы добавлять, удалять, редактировать модули, типы, поля, методы и даже проекты, как обычные объекты с помощью функций xs2InsertNode, xs2DeleteNode, xs2UpdateNode. Вот эту возможность мы и реализовали. Теперь в XS2 объекты рекурсивно описывают сами себя. Между собой любя мы называем эту даосскую хрень "ёбаной рекурсией".

Вот как схематично можно представить то, как рекурсивно описывается, скажем, объект "Книга"

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

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

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

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

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

А это скриншот первой версии (для сравнения).

(По клику доступны полноразмерные картинки).