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

Японцы придумали, как сделать так, чтобы тому, кто видит печатную рекламу, было просто запомнить, как найти соответствующий сайт в интернете. Когда я в первый раз увидел этот прием в рекламном объявлении в метро, я не придал значения увиденному - подумал, что это небольшая находка конкретного рекламодателя. Но затем, разглядывая рекламу во время долгих поездок между Токио и Татикавой, где я жил, я понял, что это стандартный прием, понятный каждому японцу. У него уже есть свой канон. Посмотрите на картинку ниже:

Здесь изображена строка поиска, в которую забито то слово, которое надо набрать в поисковике, чтобы искомый сайт выпал первым результатом. Во всех рекламах используется именно такой способ изображения этой информации: белый инпут и кнопочка "検索" ("Поиск"). Кстати, в этом объявлении, перед инпутом еще стоит призыв "Попробуйте прежде всего поискать!". По-моему, идея блистательная!

Откроем главу про повторное использование методов из «Руководства разработчика». В последнем листинге мы получаем страницу новости с блоком ссылок «еще свежие новости». Этот блок вставлен с помощью функции xs2Fetch.

Бывает, что нужно вклеить одинаковую часть несколько раз. Например, если дизайнер продублировал блок меню в шапке и в подвале страницы. Фетчим дважды? Не обязательно! Вспоминаем про параметр var и пишем вверху [div class="top-menu"]{xs2Fetch var="menu" met="menu"}{$menu}[/div], а затем [div class="bot-menu"]{$menu}[/div] внизу. Функция не выводит результат, а запоминает его в переменной, когда видит этот парметр. Но наверху страницы нам все-таки надо показать меню, поэтому сразу после фетча выводим эту переменную. Она никуда не исчезает до конца шаблона, поэтому выводим ее второй раз. Причем, с помощью классов, которые мы указали, можно задать для этих частей разное оформление.

Однако все сказанное не помогает против раскладки сайта. Именно с ней обычно связаны повторяющиеся куски. Типичный случай: в центре текст, сверху меню, сбоку анонсы других текстов, реклама и т.д. Дивами или таблицами эти части позиционируются на экране. Такая разметка образует шелуху, которую так и тянет просто скопировать. Она же не поменяется. Ага, а через неделю заказчик и говорит: «все хорошо, только ма-а-аленькая просьба — надо поменять вот это с этим, а то — убрать».

И тут тебя осеняет простейшая идея — сделать один шаблон, который будет называться «раскладка». Как его сделать? Сейчас расскажу. Но сначала  небольшое отступление: я видел движки, где эта самая раскладка была единственным способом отобразить страницу. То есть вывести статью можно только привязав ее к раскладке, которая одна для всего сайта. И если на одной странице три колонки, а на другой — только две, то в шаблоне надо ставить if и не один. Потом сайт растет, шаблон набухает такими условиями, и разобраться в нем становится невозможно. Вывод: какие страницы сливать в один шаблон, а какие не стоит — надо решать мозгом.

Итак, загоняем шелуху в отдельный метод. Для этого нам понадобится конструкция capture — стандартная штука шаблонизатора Smarty. Напишем примитивный шаблон и назовем его layout:

[html][body][head][title]{$title}[/title][head]
[body][table][tbody][tr]
[td]{$left}[/td][td]{$right}[/td]
[/tr][/tbody][/table][/body][/html]

Это раскладка, которая ожидает три блока в переменных title, left и right. Осталось их сформировать и передать. Пишем в методе, который надо показать в такой раскладке:

{xs2GetNode var="n" mod="news" NodId=$_THE.PARAMS[0]}
{capture name="r"}
     [h1]{$n.NName}[/h1]
     [p]{$n.Text}[/p]
{/capture}
{* Справа покажем текст новости. *}
{assign var="right" value=$smarty.capture.r}
{* Назначаем заголовок окна. *}
{assign var="title" value="Новость `$n.NName`"}
{* Слева покажем меню. *}
{xs2Fetch var="left" met="menu"}

И продолжаем в том же методе, чтобы передать блоки в шаблон-раскладку:

{xs2Fetch met="layout"}

И все. Впрочем, осталось еще важное замечание. Увеличение количества фетчей и вызовы capture, конечно же, утяжеляют сборку страницы. Поэтому строить так все сайты не рекомендую.

При интеграции с XS2 часто встает задача синхронизации пользователей модуля XS2 users. Иными словами при создании новых объектов user необходимо создавать иденитичные аккаунты в PHPBB, при их удалении нужно синхронно удалять пользователей форума. Кроме того, часто необходимо выводить информацию о количестве личных сообщений или ранге пользователя PHPBB в шаблонах XS2. Изрядно попотев на кодом PHPBB мы написали простенький процессор, содержащий функции, которые позволяет информацию о пользователе, добавлять и удалять пользователей PHPBB. Вот он:

<?
define('IN_PHPBB', true);
//путь к форуму относительно корня сайта
$phpbb_root_path = 'forum/';
$phpEx = 'php';
include($phpbb_root_path . 'common.' . $phpEx);
include($phpbb_root_path . 'includes/functions_user.' . $phpEx);

//Функция возвращает информацию о PHPBB-юзере
function login_user($username,$password){
    global $auth,$user,$phpEx;
    $auth->login($username,$password); 
    return $user;
}

//это функция позволяет добавить нового пользователя
//при этом мы передаем в нее урл аватары, уже хранящейся в объекте user - в этом случае картинка не будет хранится на сервере два раза
function add_user($username, $password, $email, $avatar_url, $group_id=2){
    $user_id = user_add(array(
        'username'=>$username,
        'user_password'=>phpbb_hash($password),
        'group_id'=>$group_id,
        'user_type'=>USER_NORMAL,
        'user_email'=>$email
    ));
   
    if ($user_id && $avatar_url){
        $_REQUEST['remotelink']=$avatar_url; 
        $ar = avatar_process_user($error, array('user_id'=>$user_id));
        if(sizeof($error)>0 || !$av){
            return 0;  
        }
    }
    else{
        return 0;  
    }
    return $user_id;
}

//эта функция удаляет пользователя
function delete_user($user_id,$post_username=false){
    return user_delete('remove',$user_id,$post_username);
}
?>

При тестировании 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.

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

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