Блог разработчика CMS E5

Функция автоперевода гугл не работает

2012-02-27T11:02:00.000-08:00

Связано это с тем, что с декабря 2011 года гугл изменил свой API, и теперь использование сервиса переводов платное. Необходимо привязывать эккаунт гугл к вызову библиотеки гугл и по завершению максимально разрешённого числа запросов сервис перестанет работать (хотите больше запросов - платите). Вот так всё печально. В Е5 механизм автоперевода будет осуществляться засчёт парсинга самого сайта translate.google.com, благо этот механизм уже отлажен.

Новый тип полей - папка с файлами

2012-02-20T07:15:00.000-08:00

В качестве решения избыточных проблем с обновлением шаблонов, пришла идея о создании нового типа поля - папка.

Таким образом, мы можем просто добавить к таблице шаблонов новое поле "папка", в которой указать "участвует обновлении", "не дублируется при дублировании строки".

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

Промежуточные итоги

2012-02-19T06:33:00.000-08:00

Итак, прошло чуть больше года с тех пор, как я начал активно эксплуатировать систему E5.

Какие аспекты тестирования хотелось бы отметить?

1. Обычные пользователи не могут использовать систему от начала и до конца, т.к. она до сих пор не содержит в себе пакета шаблонов (скачивая систему вы вообще ничего не получаете, только одно ядро, затем можно загрузить модули из интернета, но не шаблоны)

2. В уже установленной и настроенной системе с лёгкостью разбираются все от мала до велика (речь идёт об инструментах для управления контентом). Удобство управления особо порадовало тех, кто ранее пользовался системой Е3. Здесь нет замудрёных элементов управления - всё базируется на интерфейсе PhpMyAdmin (табличное представление данных с специальным функциональным столбцом). Я был приятно удивлён, когда узнал, что один из моих клиентов полностью разобрался в системе без чьей либо помощи.

3. Система крайне удобна с точки зрения управления информацией. Межсайтовый перенос данных, экспорт, отложенная активация, встроенные парсеры - всё это делает работу с данными сплошным удовольствием. Также радует работа с шаблонами, если Вы изучите язык шаблонизатора Е5, то разработка шаблонов и модулей превратится в одно сплошное удовольствие (по крайней мере до тех пор, пока вы не перепутаете [ с {). Я планирую сделать систему ещё удобней - встроить мастер распределения доступа (сейчас групповой доступ распределяется достаточно сложно), визуальный редактор модулей и мастер создания сайтов. Кроме этого планируется переработать главную страницу модуля и сделать сортировку и фильтрацию в таблице данных, а также сделать возможность отката изменений.

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

5. Скорость работы с админкой заметно ниже, чем в системе Е3, но в тоже время намного быстрее, если сравнивать с работой того же ShopScript. Но оно и понятно - работы по оптимизации административной части ещё не велись, упор сейчас делается на оптимизацию шаблонизатора. И в этом смысле мы находимся в проигрыше перед тем же Smarty, т.к. Smarty единовременно компилирует PHP файл на основе шаблона, который, затем, просто исполяет. У нас же компиляция шаблона происходит каждый раз, при его вызове, т.к. шаблоны настолько сложны, что их компиляция в PHP файл будет выдавать файлы, размер которых будет соизмерим с размерами самой системы. Конечно, есть продвинутые алгоритмы кеширования, но кеш как правило остаётся жёстким, т.е. полностью удаляется тогда, когда меняются данные, задействованные в шаблоне.

6. Скорость работы самой системы в среднем составляет 0.5 секунды. Это достаточно хороший результат для фреймворка, работающего через собственный интерпритатор. Было разработано свыше десяти систем кеширования и оптимизации. Вы можете использовать жёсткий SQL-кеш, кеш структуры шаблонов, кеш функций. Кроме того, некоторые шаблоны принудительно используют кеширование. Интерпритатор научился угадывать возможные запросы к базе данных и совершать их заранее, таким образом было уменьшено кол-во запросов к БД на некоторых сайтах с 400 до 100. Положительным моментом является то, что один простой хостинг (с одной БД и одной папкой на все сайты) может держать до 100 сайтов (суммарная информация на которых достягает 50млн символов, а среднесуточная посещаемость колеблется от 20 до 100 посетителей на 1 сайт).

7. Удобство разработки модулей является самой важной особенностью системы. Фактически, я могу приехать к клиенту, получить от него задание на переработку фотогалереи или же на разработку нового модуля (например "меню столовой", так, чтобы у каждого элемента мог быть целый набор фотографий, возможен переход на элемент с доступом к расширенной информацией, комментариями и т.д.). И сразу же после получения задания, я могу сесть за компьютер клиента, зайти в админку под правами суперюзера и за пару минут он получит готовый модуль. Более того - мы сразу же сможем его доработать. С каждым месяцем я всё больше наращиваю базу компонентов, для разработки модулей. Надеюсь, что скоро, разработка даже самых сложных модулей будет отнимать считанные минуты.

8. Удобство работы с шаблонами. Замучались работать с WP-TEMPLATES? Замучились разгребать тысячи файлов shop-script? Тогда Е5 - для вас! (прям по-рекламному получилось :) Сейчас весь шаблон для сайта состоит из нескольких полей - шаблон сайта, шаблон блоков для сайта и поля "таблица стилей CSS" (чтобы уж совсем лишить себя необходимости хранить что-то, что может часто редактироваться в файлах). Ещё планируется ввести "шаблон навигации". Картинки для шаблона хранятся в произвольном месте, в принципе, их можно также загружать через административную часть. Далее, вы можете настроить отдельные шаблоны для различных модулей - для фотогалереи, статей, интернет-магазина. При этом совсем не обязательно каждый раз создавать новый шаблон, вы можете просто сгруппировать уже существующие шаблоны. Таким образом, разработка нового шаблона сводится к скидыванию вёрстки (я верстаю через DreamViewer) и картинок в систему. Инсталляция шаблона заключается в вставке пары значений в тело шаблона. На самом деле, вам просто нужно подвести курсор к нужным местам шаблона и нажать на соответствующую кнопку внизу редактора (тут будет у нас "контент", а здесь будет "навигация" и т.д.) Это дело двух минут. Проводились эксперименты, когда весь сайт с нуля создавался за 1 час. При этом большая часть времени затрачивалась для рисования шаблона в фотошопе и его вёрстки в DreamViewer-е.

Нагрузочные тесты системы

2012-02-11T14:42:00.000-08:00

В данный момент, Е5 проходит ряд нагрузочных испытаний. Тестам подвергся шаблонизатор. Какие итоги можно подвести?

Во-первых, система one-time кеширования функций потребляет много оперативной памяти, из-за специфичного устройства массивов в PHP (где для каждого ключа создаётся хеш). Кеширование необходимо из-за многократного использования основных функций текстового процессора (деление строки, поиск в строке с учётом тегов, выделение текста из тегов). Даже в неочень сложных проектах, вызов одной функции может доходить до нескольких тысяч раз. Кеширование минимизирует расходы процессорного времени, однако съедает ОЗУ.

Во-вторых, система всё ещё плохо работает со строками. Сейчас я занялся глубоким дебагам системы, на выявление самых тяжёлых мест в коде. Был переписан ряд функций, но результат всё равно остался неудовлетворительным. Возможно, я введу полную компиляцию шаблона в некий аналог PHP кода, который будет содержать прямые инструкции по обращению в БД. Но что-то мне подсказывает, что управляемые шаблоны тем и отличаются от того же Smarty, что их невозможно скомпилировать в исполняемые php файлы. Или же получившаяся компиляция не будет уступать по объёму исходный код самого шаблонизатора.

В-третьих, я подсмотрел на хабре сравнение Smarty и Twig-а, и решил провести аналогичные тесты. 2ой тест (вывод 10 полей из 10000 элементов массива) Е5 отработала аж за целых 45 секунд. Конечно же это никуда не годится и я буду это исправлять. А вот 1ый тест (вывод 10000 переменных) Е5 выполнила за тот же временной интервал, что и Smarty (16 секунд). Только вот smarty один раз скомпилировал и потом выполняет этот код за сотые доли секунды, а Е5 всегда будет выполнять его по 16 секунд.

Новые функции движка

2012-01-19T00:30:00.000-08:00

Для более удобного конструирования модуля я продолжаю добавлять новые языковые конструкции и элементы.

Для выхода интерпритатора из тела текущей обрабатываемой части модуля, была введена команда [xbreak]. А команда [break] теперь будет служить исключительно для выхода из цикла или условий.

Для определения текущей, найденной посредством URL-декодирования, части, теперь служит команда [selpart], которая вызывается из модуля (например [cm.selpart] - выбранная часть текущего модуля).

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

Тем более, кроме конструктора есть более важные задачи, такие, как дообновление модулей, обновление таблиц модулей (например, для загрузки необходимых шаблонов). Хотя именно конструктор выделяет E5 от других подобных систем.

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

Добавлена поддержка работы с COOKIES

2012-01-17T05:27:00.000-08:00

Добавлено два простых оператора для работы с переменными COOKIES - cook и cook2.

Теперь веб-конструтору доступна работа с переменными браузера пользователя. Чтение и запись COOKIES работает точно также, как чтение и запись обычных переменных. Единственное чего нет, это ограничения времени жизни. По умолчанию переменная живёт 1 месяц.

Cook призвана работать с обычными текстовыми или числовыми переменными, в то время, как cook2 работает с массивами и объектами (с массивами cook также справляется, но в этом методе для каждого элемента массива создаётся отдельная переменная в окружении, что делает невозможным удаление всего массива). Cook2 работает засчёт сериализации данных.

Возможные варианты использования:

[cook2.basket[item]=count] - добавит товар item в корзину покупок, в количестве count
[cook2.basket=''] - обнулит корзину

[if cook2.basket[item]>0] товар находится в корзине [else] товара в корзине нет [/if]

Вывод товаров для корзины
[tree cook2.basket]
Товар "[index.e5.name]", количество [value]
[/tree]

Вести с полей за первую рабочую неделю января

2012-01-11T03:41:00.000-08:00

Итак, что же у нас нового. Начну с последних новостей.

Прикручены отображения CloudyZoom и Zoomy

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

Плагин Zoomy ужасно показал себя в IE (куча ошибок, всё отваливается) и вообще очень дёрганая штука. Весь день провёл в попытках заставить работать его с продолговатыми изображениями (ширина которых меньше ширины линзы - раньше плагин или падал на них или отображал их в левом углу линзы, так что и не разглядишь). В итоге были поставлены пару тройку костылей и всё заработало.

Умные блоки

Меня всё время мучала мысль - а что будет, если в рамках одного модуля мы вызовем блок из совсем другого модуля? Сам вызов блока трудностей не вызывает, а вот его идентификация по URL (например определение текущей просматриваемой статьи) заставляет мозг попотеть. Как например узнать какая статья текущая, если модуль статей ещё небыл вызван (например это левый или верхний блок, который идёт до основной модульной части)?

Суть:

По этому при вызове блока от стороннего модуля, приходится вызывать URL-Detection, для определения текущего элемента вложенного модуля.

Такая схема работает если мы имеем структуру URL: www.site1.ru/Часть урл от модуля1/Часть урл от модуля 2. Т.е. блок от второго модуля будет определять текущую строку, даже если его вызвать в первом модуле (до определения 2ой части URL). А вот если между ними будет URL некоего третьего модуля, то такая схема скорее всего работать не будет (я ещё не проверял, т.к. сайты с ткаими сложными структурами ещё не встречались). Меня беспокоит, что такой подход сможет нарушить URL разбор. Особенно в том случае, если URL какой-нибудь фотогалереи совпадёт с URL-категории интернет-магазина.

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

Начата разработка интернет-магазина

Неделю назад я занялся переносом одного крупного интернет-магазина на Е5. Это было рискованное дело, если учитывать тот факт, что модуля магазина на Е5 как такового ещё нет.

Структуру магазина удалось создать за несколько часов. Виной тому отсутствие возможности подгрузки шаблонов таблиц с сервера и отсутствие шаблонов полей (поля URL транслитерования и миниатюры изображений достаточно долго делать).

Структура характеристик товара (поля описаний, цена, валюта, префикс валюты, вес, еденицы измерения) добавилась очень быстро. Если бы это делалось на голом PHP, то заняло порядка суток работы. А тут - "тык", "тык", "бац" и готово! Просто настраиваешь нужные связи и всё готово.

За сутки с небольшим была забита первая тысяча товаров. Скорость заливки товаров медленней, чем это было на Е3. При этом скорость зависит от количества товаров в категории. В начале заполнения всё работает шустро, а когда кол-во доходит до сотни, товар может добавлятся от 3х до 7ми секунд. Видимо, нужно оптимизировать функцию автоматической генерации URL.

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

Интернет-магазин на Е5 будет бесплатным.

2011 год закончился. Подведём итоги

2011-12-31T18:54:00.000-08:00

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

Итак, что же было сделано в 2011 году?

Нужно признаться, что львиная доля разработки (и самые важные шаги) были проделаны осенью и зимой 2010 года. 2011 год стал годом доработок, допиливания и сорвешенствования системы.

За ушедший год мне не удалось реализовать даже половины идей, которые были нагенерированы в 2010 году. Более того, to do list пополнился парой сотен наименований.

Из основных нововведений стоит отметить следующие вещи:

Права доступа
Загрузка модулей и компонентов
Инсталлятор

В этом году наконец-то родилась концепция визуального редактора шаблонов (которая практически реализовалась, ждём редактор в январе).

Весь год система обкатывалась на более чем 30 сайтах и с ней успели поработать порядка 50 человек. Были написаны десятки модулей и разных компонентов.

Какие планы на будующий год?

Самое главное - дописать визуальный редактор шаблонов. А также очеловечить систему. Сделать нормальный дизайн админки (с возможностью его выбора, виджетов и локализаций). Допилить обновления модулей и сделать возможность подгрузки экземпляров модулей (для того, чтобы пользователь ставил не "лысую систему", а уже с готовыми шаблонами). И, конечно же, сделать человеческу справку с множеством видео-примеров (и разнообразные "мастера", облегчающие работу с системой).

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

Надеюсь, система не разочарует вас! С наступающими праздниками!

Очередная оптимизация Е5 и некоторые новости

2011-12-27T03:25:00.000-08:00

Итак, я опять оптимизировал работу системы

В прошлом сообщении об оптимизации, я кажется упоминал о кешировании схем шаблонов. Оказалось, что обработчик, просматривая длинные шаблоны (например длинные тексты страниц сайтов, на предмет содержания в них виджетов), тратит на это очень много процессорного времени. В текущей сессии (запуске скрипта/загрузки сайта) шаблонизатор сохраняет кеш в спец.массив, который держиться в оперативной памяти до завершения работы скрипта, чтобы два раза не пробегать через весь шаблон.

Кеш представляет из себя массив конкретных действий шаблонизатора, что лишает его необходимости перебирать весь шаблон целиком (а это бывает очень полезно, когда один и тот же шаблон вызывается по 1000 раз за время генерации какой-нибудь страницы прайс-листа / речь идёт о шаблоне вывода товара, как пример).

Новая система оптимизации позволяет сохранять этот кеш на жёсткий диск сервера, чтобы вообще не обрабатывать шаблон. Это создаст дополнительную нагрузку при первой загрузке шаблона, однако ускорит все остальные загрузки (а шаблоны меняются очень редко, по сравнению с данными). Эта оптимизация включается опционально в настройках системы.

На самом деле я разработал её около месяца назад, но тесты выявили её не эффективность, и только недавно я понял, что допустил опечатку в имени переменной кеша. Таким образом, эта технология вообще не использовалась при прошлом тестировании. Исправив досадную опечатку я провёл повторный тест, который выявил 50% повышение скорости генерации сайтов с длинными шаблонами и страницами. Теперь скорость работы движка не зависит от объёмности шаблона.

Однако в целом скорость работы меня не устраивает. Возможно в этот же кеш шаблона я добавлю все необходимые подгрузки строк и столбцов... Сейчас обычный сайт грузится 0.37с (я уменьшил кол-во запросов к БД, но вероятно из-за этого немного упала скорость и увеличился объем потребления памяти, так для загрузки сайта нужно от 6 до 15мб ОЗУ, а для загрузки некоторых страниц админки - аж 20мб), а интернет-магазин загружается 1.2с

Эти показатели намного лучше показателей многих современных движков, однако это намного дольше, нежели использование движков на голом PHP. Будем оптимизировать дальше.

Что нового?

Проверка скорости веб-сервера (E5 SpeedTest)

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

Новые функции дебагера

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

Е5 и ЧПУ

Оказывается, не у всех веб-сервер поддерживает mod-rewrite. И к моему удивлению, оказалось, что большинство CMS умеют работать и без mod-rewrit-а (многие из них разрабатывались ещё до использования ЧПУ в CMS). Е5 совершенно не умеет работать без ЧПУ. И дело не в разборе адреса. Можно было бы сделать тупо /index.php?url=URL , но вот сама генерация URL-ов при конструировании модулей предполагает именно использование ЧПУ (я же не могу обязать конструкторов модулей делать два варианта модулей? так ведь?). Есть правда выход в виде неприглядного костыля - обрабатывать выходной код на наличие внутренних ссылок и менять их на index.php?url=URL

Трудности установки

Я столкнулся с некоторыми трудностями при автоматической инсталляции системы (функция "внедрение"):

1. Многие серверы бреют с доступом к БД при удалённой установки (хотя мне это не совсем понятно, т.к. реально установка проходит не удалённо). На некоторых серверах необходимо в настройках MySQL дать юзеру возможность удалённого управления БД (хотя я всё делал через localhost, не знаю в чём косяк);

2. Некоторые серверы запрещают функцию ftp_chmode (пришлось дописывать установку нужных прав на устанавливаемой системе, так что теперь ftp_chmode для нас не проблемма);

3. Для кириллических доменов (при установки системы на них) необходимо указывать их punicode;

4. На раздающей машине (с которой я устанавливал E5 на другие сервера) в .htaccess была включена строчка SecFilterEngine Off (отключала фильтр безопасности хостера, который блокировал половину нужных Ajax запросов, в частности мой мульти-аплодер с image-resize on client side). Из-за этого, после установки система просто отказывалась запускаться (сервер брил меня с 500ой ошибкой, именно из-за этой строчки в .htaccess).

В принципе, все эти 4 пункта не несут никакой серьёзной проблеммы, а 2ой пункт вообще решаем, т.к. к Е5 подключён модуль трансформации punicod-а (спасибо Matthias Sommerfeld за это).

E5 и MVC

2011-12-27T02:37:00.000-08:00

Сейчас модно стало писать CMS на базе принципов, заложенных в MVC. Изложу этот принцип в трёх словах: Модель, Контроллер, Представление (браво! я гений! апплодисменты мне!).

А если быть серьёзными, то в случае с MVC весь движок делится на 3 части - работа с данными (модель), логика программы (контроллер) и шаблоны вывода (представление). Как это может выглядеть на примере? Административны модуль работает с данными, клиентская часть обрабатывает данные и засовывает их в шаблон вывода. Итого мы получаем готовый сайт.

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

Например, мы решили сделать мультидоменную CMS на базе MVC. Сделали движок (MC) и написали шаблоны (V). Если у нас один сайт и один шаблон - проблем нет. Просто установили движок, выбрали шаблон и работаем. А теперь представим, что сайтов у нас 100 и на половине из них разные страницы используют разные шаблоны вывода. Как быть? Придётся привязывать V к M, делать дополнительные таблицы, которые связывали бы страницы сайтов с шаблонами. Дак почему бы в эту таблицу связей вставлять не ссылку на локальный физический файл шаблона, а сам код шаблона? Таким образом V превращается в M. При этом с логической точки зрения, это выглядит как MVC, но при этом V является частью M.

В Е5 шаблоны создаются в виде таблиц и являются такими же данными, как и всё остальное в системе. Более того, содержание некоторых элементов (например текста страниц) само по себе является шаблоном, т.к. позволяет включать в себя разнообразные виджеты и модули. Признаюсь, это и удобно и неудобно одновременно. Поскольку в Е5 шаблоны являются также элементами управления (ещё одна вещь, которая отдаляет Е5 от классической MVC), то большенство частей некоторых модулей просто занимаются тем, что вызывают тот или иной шаблон. В итоге в модулей только одна таблица используется для хранения данных и 50 для хранения шаблонов (или 1, но с 50ю полями).

Какие плюсы такого подхода?

1. Комбинирование шаблонов. Мы можем использовать группу шаблона, а можем отдельно взять шаблон корзины товаров и сопоставить его с шаблоном вывода товара магазина (для интернет магазина). Хотя такое решение возможно и на базе MVC, но реализация внешней перегруппировки шаблонов между собой (на уровне C) дело тяжёлое.

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

В Е5 вы можете присоеденить параметр "шаблон" к модулю или к таблице (например "шаблон сайта такого-то" или "шаблон страницы такой-то). Затем, вы решите что одни и те же страницы должны показываться в разном дизайне разным группам пользователей. И сделаете второй параметр "Шаблон для зарегистрированных пользователей", который также привяжите к таблице шаблон.

Можно делать подшаблоны, в таблицу шаблонов можно сделать подтаблицу фотографий, куда пихать все фотографии, используемые в шаблоне и т.д.

Конечно я очень путанно описал эту возможность, но поверьте - она экономит массу времени и сил. Часы работы и постоянное решение логических неувязиц (путём включения дополнительных таблиц и полей), которые понадобились в обычной CMS заменяются на комфортное пятиминутное конструирование в E5.

3. Разделённое и совместное использование шаблонов и HTML-верстальщики. Благодаря гибкой системы конструирования структур данных в Е5 вы сможете назначать шаблоны как Вам заблагорассудится. Можете сделать общий шаблон для всех страниц одного сайта или же один шаблон на 5 сайтов. При этом каждая отдельная страница сайта может обладать своим шаблоном, также как и страница 404 ошибки.

Вы можете сделать так, чтобы в одно время суток показывалась одна группа шаблонов (или шаблоны с параметром "только днём"), а в другое время - с параметром "только ночью". Можно сделать возможность посетителям самим менять шаблон для сайта и сделать разные шаблоны для разных групп пользователей. При этом всё это делается в рамках самого движка Е5 без всяких шаманских обрядов с кодом.

Если на одном сервере вы держите целую сеть сайтов (например, вы руководитель веб-студии), то вы можете сделать отдельную группу верстальщиков, которые будут иметь доступ к редактированию шаблонов.

Какие минусы такого подхода?

Минусом естественно является немного непонятная логика процесса. Получается, что V в Е5 является частью M и может выполнять функцию C (синтаксис для C и V одинаков, также как и набор решаемых задач). Так, один шаблон может просто выводить сайт, а другой при этом активно работать с данными (например включать в себя анонсы новостей, хотя лучше это делать на базе системы блоков сайта). Единственное различие View от Controller в Е5 в том, что может быть несколько View на один Controller.

Есть сейчас в Е5 такой пример. Это модуль "Статьи", а конкретно его функций вывода списка статей. В блоке Controller (в теле части "вывод списка") содержится только фраза cex.tpl.shell (запустить шаблон текущего экземпляра модуля). А уже в самом шаблоне содержится и сама сортировка статей и т.д. Т.е. по сути вообще нет необходимости в части "вывод списка". Почему именно так? Да потому что на одних сайтах статьи нужно выводить по дате их написания, в других случайным образом и т.д. И всё это должен делать один модуль. По этому многие задачи ложаться на сам шаблон, а вот контроллеру не достаётся ничего. Сторонники MVC сказали бы, что в данном случае нужно отдельно писать C и V, но зачем?

Вообще изначально C от V стали отделять для удобства верстальщиков. Но в Е5 синтаксис шаблонизатора использовать не обязательно. Верстальщик может воспользоваться визуальным редактором шаблонов (который сейчас в разработке). Он вообще не подразумевает никакого ковыряния в коде и на нём можно писать как View, так и Controller.

Как я хотел переделать Е5 под MVC

Буквально сегодня, идя по улице, покрытый мокрым снегом с ног до головы, я размышлял над тем - а не сделать ли отдельно View для Е5? Т.е. такие виды частей, которые отделялись бы как View и которые имели бы разное содержание в зависимости от выбранного экземпляра модуля. Но я пришёл к тому же выводу, что и описал в этой заметке - это не практично и пришлось бы вставлять много костылей, чтобы заставить веб-проекты работать на MVC.

В частности, пришлось бы делать возможность привязки содержимого части модуля к экземпляру, и возможность привязки экземпляра части (а это может быть не тоже самое, что экземпляр модуля) к строке данных (например к странице сайта). И в итоге мы получим всё тоже самое, что и имеем на текущий момент, только в красивой обёртке (но внутри всё изувеченное, с кучей костылей). Возможно я ограничусь введением галочки для таблиц "таблица шаблонов". Просто чтобы она висела отдельно от основных таблиц... но надо ли оно?

Резюмируем

Я разрабатывал Е5 не на базе MVC (а на базе своих представлений о веб-разработке), однако вы можете использовать модель MVC в создании своих модулей в Е5. Более того, я не представляю использование MVC для разработки поточных веб-приложений, имеющих сложную логику (примеры выше).

Как установить систему управления содержанием Е5

2011-12-21T12:20:00.000-08:00

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

Теперь мы поговорим об обычной "ручной" установке.

Шаг 1. Для начала нам необходим сам файл инсталлятора. Пока система не прошла бета-тестирование получить файл можно будет только по запросу на этот почтовый ящик: nerd220@rambler.ru

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

Шаг 2. Закачиваем файл в папку веб-сервера и заходим на связанный с ней домен (например test1.ru). В появившемся окне видим успешно ли распакована система, и (если всё хорошо), заполняем реквизиты MySQL.

Шаг 3. Далее нас направляет в меню обновления, где предлагается загрузить необходимые модули (сама система абсолютно лысая и содержит в себе только движок и изображения для админки).

Рекомендуется загрузить модули: Содержание, Статьи и все предлагаемые компоненты (вместе со статьями вам загрузятся комментарии и фотогалерея). Загрузка продлится от 30 до 60 секунд.

Если с первого раза загрузить все компоненты не удалось (например, на вашем сервере установлен маленький тайм-лимит для php-скрипта), то попробуйте загрузить их в 2 этапа. Больше всего будет загружаться CKEditor с его файловым редактором ElFinder (который поддерживает права доступа к папкам, задаваемые системой).

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

В принципе, я только что придумал как можно реализовать такую схему самым простым способом. Для этого разработчик модуля будет указывать таблицы, участвующие в обновлении. Для этих таблиц будут доступны два дополнительных поля - "участвует в обновлении" и "связный каталог" (где, например, будут лежать все картинки для дизайна шаблона". Отдельную таблицу данных под это заводить не надо (также как и отдельного поля). Лучше использовать таблицу row_values с отрицательным значением value_row и с путём к папке вместо value_value.

Шаг 4. Указываем логин и пароль для главного администратора (в настройках), там же задаём установки крон таба (запуск по крон-табу хостинга, или запуск вместе с запуском системы, например, при заходе посетителей на сайт).

Шаг 5. Создаём экземпляр базового модуля. Например, в основе сайта у нас будет модуль "Содержание". Преходим в него и создаём новый экземпляр, который назовём "Сайт 1" (если к моменту прочтения вами этого сообщения я не ввёл возможность прямой загрузки шаблонов, то вначале придётся добавлять шаблон). После этого мы можем создавать страницы на сайте и привязывать их к другим модулям (у которых вначале также нужно создать экземпляры).

Шаг 6. Далее создаём зону для нашего домена и её зеркало с www (если это необходимо). Зону сразу же привязываем к нашему модулю "Сайт 1".

Та-да! Сайт готов.

Естественно у многих вызовет вопрос "почему так много орфографических и пунктационных ошибок в этом тексте!", но я и не претендую быть грамотеем. Поверьте - в моём PHP коде их намного больше ;)

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

Плюс - укомплектую начальный пакет установщика всеми необходимыми модулями, шаблонами и картинками. И пускай первый экземпляр будет создаваться при установке модуля, ведь не всем нужен второй ;) Также и зона сразу будет привязываться к установочному домену автоматически (как это сейчас происходит с зоной админки) и связываться с модулем "Содержание" (это будет опционально - при компиляции пакета установщика).

Вот такой я обещатель. Уже можно отдельно сайт открывать, на котором размещать только "то, что должно быть в Е5".

Изменения в инсталляторе и PHP Self Extractor

2011-12-16T08:29:00.000-08:00

Возможно я уже рассказывал вам о так называемом "внедрении". Эта возможность позволяет производить установку системы с одного веб-сервера на другой, используя FTP. Это позволит устанавливать Е5 без необходимости самостоятельной загрузки файлов на FTP сервер.

После запуска beta-версии системы (для этого я уже приобрёл площадку rucms.org) можно будет не только скачать её архив, но и воспользоваться онлайн-инсталлятором. Многих пользователей смутит необходимость указывать FTP-реквизиты, однако код системы открыт (в том числе и код инсталлятора) и вы можете легко убедиться, что ваши данные не уйдут "на лево".

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

PHP Self Extractor (Та да!)

Т.е. один сервер посылает другому всего один php файл, который состоит из двух частей: распаковачный модуль и сжатые данные системы (системные файлы и изображения), упакованные GZIP Deflate сжатием (только inflate разрешён в PHP до 5ой версии, в отличие от GZEncode).

Возможно, в будущем сама система будет скачиваться не архивом, который нужно руками распаковать где-нибудь на рабочем столе и переправить по-файлово через FTP-сервер. А в виде одного файла. Хотя в каком будущем? Наверное так и сделаю :) Ведь возможность уже есть.
В той же Joomla компоненты можно устанавливать с помощью одного GZIP файла. Чем мы хуже? Тем более, что у нас есть Self Extractor!

В принципе, можно было бы обойтись и двумя файлами: один установщик, другой - сжатые данные (вспомним те же плагины жумлы). Но одним как-то лаконичней. Тем более, он удаляет себя после распаковки, дабы не оставлять мусор.

Авто определение родительского каталога домена

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

Тут я немного облажался, т.к. разбираться с обычным LIST достаточно долго, учитывая разные ответы FTP сервера для разных операционных систем. По этому я использовал стандартную команду NLIST, которая однако не сообщает - файл она выдала или папку. По этому мой скрипт пытается пихать свои файлы в файлы (например /pub/index.html/script.php). В виду отсутствия альтернатив пришлось использовать именно этот метод. Можно было бы предварительно проверять, можно ли зайти в эту сущность как в директорию, но по времени это заняло бы ровно столько же времени.

Скрипт поиска домашней директории для домена был удачно опробирован на хостинге SWEB.

Зачем это нужно, когда система сама определяет DOCROOT? Всё очень просто: для успешной установки, мы должны знать КУДА извлекать файлы на FTP сервере и автоматически запускать нужные установленные файлы, для обновления БД. А как их запускать? Только через GET запрос к удалённому серверу (я не рассматривал варианты поиска php.exe и запуск скрипта через него, с помощью shell, т.к. это маловероятно на современных хостинг-платформах).

Сделаем всё за 1 раз

Раньше установка проходила в два этапа:

Верификация реквизитов (FTP, MySQL, DomainRoot)
Копирование файлов системы

Теперь всё происходит за 1 раз. Зачем заставлять пользователя нажимать лишнюю кнопку? Тем более, что теперь скорость установки увеличилась почти в сто раз. Раньше установщик просто копировал всё необходимое для запуска автообновления на удалённой машине, а затем запускал его. Естественно, что обновление, при отсутствии большинства файлов, будет идти несколько минут.

Плюс была масса FTP запросов (которые идут очень долго, т.к. FTP сервера у большинства хостеров очень тормозят). Теперь же используется всего два запроса - перенос файла системы и запись файла конфига. Автообновление также запускается (для установки БД и .htaccess файлов), но по времени оно идёт всего несколько секунд.

После установки методом "внедрения", системе автоматически присваивается в качестве сервера обновлений адрес той машины, с которой она была установлена. Внедрение возможно только в том случае, если в системе-сервере есть зона обновлений. Например SiteURL/update (именно с этого адреса будут в последствии обновляться все установленные с неё системы).

Внутренний буфер обмена

2011-12-01T13:02:00.000-08:00

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

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

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

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

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

Система Е5 прекрасно обходилась без буфера обмена. Достаточно было скопировать или клонировать объекты на месте (в текущем разделе), а затем просто сменить копиям родителя или экземпляр. Такой способ дал трещину тогда, когда пришлось переносить элементы между двумя, совершенно не связанными, структурами.

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

Также есть желание сделать межраздельный буфер. Сейчас мы можем работать с буфером в рамках определённой таблицы (т.е. мы не можем скопировать элемент Новость в таблицу Фотогалереи). Есть желание сделать возможность форсированного буфера. Т.е. вначале мы определяем сопоставления полей, а затем делаем впрыск нужной информации. Думаю пользователи оценят такую гибкость системы.

Работы по оптимизации

2011-11-28T16:53:00.000-08:00

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

На тестовой версии Е5, которую я сейчас обкатываю, размещается порядка 30и сайтов (в рамках одного виртуального хостинга). Суммарный объём информации на всех сайтах - 89.4мб.

В этих 19 таблицах хранится информация о 30и сайтах
(13,247 строк информации)

До оптимизации, скорость загрузки типовой страницы колебалась от 0.6 до 0.8 секунды. На страницах повышенной сложности (главная страница интернет-магазина, большой каталог статей с архивом) скорость загрузки падала до 3 секунд. На самых сложных ресурсах (каталог недвижимости, объёмный прайс-лист) скорость могла упасть до 15 секунд.
Кроме того, количество продуцируемых запросов могло достягать нескольких тысяч, а количество затронутых строк - десятков тысяч (на том же портале недвижимости, в каталоге фигурирует порядка 10 тысяч вариантов). В среднем уходило 300 запросов.
Для предотвращения долгих запросов Е5 использует всевозможные варианты кеширования шаблонов. Но согласитесь, один кеш не спасёт, особенно в тех случаях, когда информация постоянно меняется.

Мне удалось обнаружить основную причину долгих загрузок и большого количества обращений к БД. Причиной всему было поэтапное извлечение данных из базы данных. Наш интерпритатор шаблонов просто не мог угадать какие именно данные будет использовать пользователь в своём шаблоне. По этому, вместо того, чтобы выгружать вообще все данные (что совсем нелогично), интерпритатор загружал их постепенно, по мере сталкивания с данными в шаблоне. Следовательно, напрашивался вывод - чтобы обеспечить нормальную выгрузку данных, нужно научить интерпритатор видеть какие данные могут понадобится в том или ином шаблоне.

Какие работы по оптимизации были проведены?

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

2. Переработана функция обработки текста explodeA. Теперь она работает в 10 раз быстрее. Эта функция может вызываться несколько тысяч раз во время загрузки одного сайта (благо функция очень лёгкая и быстрая);

3. Добавлена возможность физического кеширования направляющих шаблона. Во время чтения шаблона интерпритатором, он придаёт ему удобную для работы форму - в виде схемы. Эта схема и кешируется на жёстком диске сервера. Итого мы получаем -30% к первому запуску страницы и +15% к скорости всех дальнейших запусков (при этом кеш является глобальным, без привязки к адресу и т.д.)

4. Добавлены новые виды кеширования шаблонов (^# - кеш, независимый от адреса, но зависимый от входящих переменных / ^* - кеш, зависимый только от экземпляра текущего модуля). Для статичных блоков рекомендуется писать ^* в самом начале шаблона.

5. Включён кеш парсинга строки данных (для функции parse_row)

А как насчёт результатов?

После оптимизации мы получили следующие цифры:
Время загрузки простого сайта - 0.17 секунды
Время загрузки среднего сайта (каталог статей, интернет-магазин) - 1 секунда
Время загрузки крупного сайта (портал недвижимости, страница со всеми объявлениями) - 5 секунд

При этом количество запросов к БД удалось уменьшить до 60-140.

Фактически систему удалось ускорить в 3 раза,
при этом в 3 раза сократив кол-во запросов к БД.

Даже не смотря на такое ускорение, система ещё не подходит для разработки порталов и интернет-магазинов. Для сравнения - главная страница топовых интернет-магазинов на системе Битрикс загружается 0.5 секунды.

Сейчас Е5 прекрасно справляется с небольшими сайтами компаний, каталогами статей и блогами. Моя цель - довести скорость загрузки интернет магазина и портала до 0.3 секунды.

Стоит отметить, что с кешированием это возможно уже сейчас. Тем более, что в Е5 оно бывает очень многих видов. Например, сам разработчик модуля может установить кешируемость определённых элементов (некоторые кешируются на время, некоторые - до изменения элемента). Кроме того есть кеш SQL запросов, жёсткий кеш шаблонов (кешируется вообще всё), кеш функций и кеш структуры направляющего шаблона (то, о чём я писал в пункте 3 этого поста).

Настройки безопасности - продолжение

2011-11-25T15:46:00.000-08:00

В прошлых записях я уже писал о неоднозначных ситуациях с правами доступа к разным элементам системы. Поскольку система Е5 это ещё и фреймворк, приходится предусматривать самые разнообразные настройки прав.

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

Спорных ситуаций возникает тысячи. Например, что делать если пользователь состоит в двух группах - в одной из них ему разрешено редактировать эти новости, а в другой запрещено? В таком случае доступ складывается в пользу разрешить. А что если, в одной группе пользователю разрешено редактировать вообще все строки, а в другой группе запрещено редактировать "Главные новости сайта"? Тогда редактирование будет запрещено. Т.к. более тонкая настройка доступа перекрывает глобальные настройки.

Итак, кто кого перекрывает и как?
Попробую расписать всё по порядку.

1. Смотрим глобальные настройки доступа к строкам ("все строки"), вначале проверяем значения "по умолчанию", затем перебираем все группы, в которых участвует пользователь и в конце концов добавляем личные настройки самого пользователя. Сложение идёт в пользу "Разрешить". А вот точный порядок сложения доступов: Не задан -> Запретить -> Разрешить только для элементов, созданных автором -> Разрешить.

2. Смотрим настройки для всех таблиц текущего модуля. Перебираем таким же образом, как и в предыдущем случае (настройки по умолчанию -> настройки для групп, в которых участвует пользователь -> частные настройки пользователя). Доступ также складывается в пользу "Разрешить".

Теперь складываем полученные доступы из 1ого и 2ого пунктов, но сложение идёт в пользу "Перекрыть". Т.е. настройки для таблиц модуля будут перекрывать настройки всех строк в том случае, если они заданы.

3. Смотрим настройки для конкретных таблиц модуля. Всё делаем по аналогии с пунктом 2. И также складываем эти настройки с получившимися из пунктов 1 и 2 способом "Перекрыть".

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

Такая логика не прозрачна, по этому она была внедрина в систему буквально сегодня (через 6 месяцев после запуска системы доступов). Старая система доступов к строке выглядела иначе. Она обрабатывалась для каждой группы отдельно способом "Перекрыть", а затем складывалась в пользу "Разрешить". Т.е. обрабатывались сразу все уровни доступов. Теперь же я решил сделать отдельную обработку для каждого уровня доступов (все строки -> строки модуля -> строки таблицы). Вначале выбирается уровень, а затем начинают перебираться все группы и складываться разрешения в пользу "Разрешить", но при сложении с следующим (более тонко-настроенным) уровнем, доступы складываются в пользу "Перекрыть".

4. Складываем получившиеся доступы с доступом к текущему экземпляру. Сложение идёт в пользу "Перекрыть", т.к. указание экземпляра является самой тонкой настройкой.

Зачем так усложнять?

Система изначально позиционируется как мультидоменная. Более того, была задумка предоставлят систему веб-студиям, чтобы они могли на одном сервере (в одной папке и с одной базой данных) размещать большое количество клиентов таким образом, чтобы клиенты работали с системой индивидуально (не догадываясь о наличии в системе других сайтов, пользователей и т.д). Для этого был реализован доступ по экземплярам.

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

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

Вставка значений в редактор шаблонов

2011-11-23T13:15:00.000-08:00

Для каждого начинающиго "шаблониста" основной проблеммой является постоянный поиск нужных комманд и названий полей. Например, чтобы вставить в шаблон типичного модуля на смарти дату или текст, вам нужно точно знать как программист забил эти значения в шаблон. И зачастую программисты держат эту информацию в секрете. Но даже если разработчик модуля предоставляет полное руководство по его шаблонизированию, хранить в памяти набор из нескольких сотен непонятных названий ( {forum_first_topic_title} ) дело тяжёлое.

Месяц усилий не прошёл даром. И вот уже появилось нечно, с помощью чего можно руками составлять неплохой HTML шаблон, зная лишь несколько принципов работы системы.

Вставляем часть модуля, с нужными параметрами

Сейчас есть два вида диалогов - вставка значения и вставка условия. Диалог значения может быть жёстко привязан к нужному результату. Например, в перебор мы можем вставить только массив значений, а в текст - только текст.

Вставляем условие

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

Выбираем массив для перебора

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

Например, выбрав текущий модуль, далее мы выбираем модификатор модуля "Текущий экземпляр" (переходим к активному экземпляру), затем выбираем таблицу этого экземпляра "Статьи" и к ним модификатор "Активные строки". Таким образом, в перебор у нас попадут все текущие статьи.

Визуализируем управляющий шаблон: первые итоги

2011-10-27T14:59:00.000-07:00

Как уже писалось в предыдущей статье про редактор, у меня было на выбор две идеи:

Автор пишет весь шаблон на визуальном редакторе (без HTML и CSS - они генерируются редактором), и туда же втыкает структуру управляющего шаблона
Автор пишет шаблон на HTML+CSS, но составляет его из кусочков в дерево шаблона (т.е. шаблон состоит из элементов, которые объединяются друг с другом с помощью переборов и условий)

Выбор пал на 2ой вариант, т.к. он менее сложный и понадобится в любом случае. Лично я на одном визуальном редакторе далеко не уеду.

И тут возникла первая сложность. Дерево шаблона будет состоять из редактируемых (!) элементов, в каждый из которых можно воткнуть кнопку-картинку. По этому пришлось иметь дело с DIV contentEditable. Т.к. мне показалось, что iframe с designmode жрал бы больше ресурсов и вообще использовать его 100 раз на одной странице как-то необосновано.

Как уже говорилось, пользователь будет писать шаблон на HTML и CSS, вставляя в него элементы управления, которых будет 3 и они будут двух типов. 1ые - делящие один элемент на несколько (условия, переборы), 2ые - вставляемые в виде кнопки посреди самого элемента (вывод переменных, функции и т.д.)

Кто сталкивался с contentEditable дивами знает через какое место ими можно управлять. В итоге было перелопачено пару сотен сайтов по этой теме. Первая цель была эмуляция Таба и замена Enter-а с <p></p>, на <br>. Таб эмулировать удалось (через \u2003), однако каретка передвигается вперёд только в IE (пробовал способов 10 эмуляции keypress, и где-то столько же способов обращения к selectionRange - не получилось). Хотя на одну позицию курсор всё таки удавалось сдвинуть, но после этого вылетал jQuery с неопределённой ошибкой. С ентером дела обстояли хуже. Перехватить его и заменить на <br> усилий не составило, а вот передвинуть туже самую злосчастную каретку так и не получилось. В итоге оставил <p></p>, но стиль у них сделал такой, чтобы были как <br>.

Следующей целью была возможность вставления подэлементов. Вначале я хотел сделать вставку элементов в элемент, но потом решил разделять родительский элемент на две части (до вставки и после вставки), а посередине вставлять подэлементы. Также как и в прошлый раз проблемма встала при работе с кареткой текста (нужно было определить её позицию). Для этого чудом нашёлся совет разработчика редактора elRight, который советовал вставлять <span> на место каретки (стандартным методом pasteHTML), а затем плясать от него. Я сделал проще - вставил на это место текст, по которому в будующем он разделялся на две части. Если часть текста была выделена - она сбрасывалась в дочерний элемент.

Как видно из скриншота, у меня готова реализация структуры шаблона. Работают кнопки "Условие", "Перебор" и "Удалить" (кстати после удаления элементы до и после удалённого места складываются в единое целое). Теперь осталось дело за реализацией окна "Параметры" и "Вставка значения". Думаю, это самый сложный технический момент. Именно в нём произойдёт интеграция редактора шаблонов с системой Е5.

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

Немного о системе разбора URL

2011-10-24T14:29:00.000-07:00

В Е5 внедрена система автоматического разбора URL.

Система состоит из сладующих частей:

Зона (домен / домен+папка / любой домен + папка)
Части модулей, предназначенные для разбора URL
Таблицы, имеющие URL-столбцы, связанные с частями модуля

Как это происходит? Нажимаем "Дальше" и смотрим...

1. Разбор зоны

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

Зона, в свою очередь, ссылается на определённый модуль и на определённый его экземпляр.
Например у зона "сайт1" может ссылаться на модуль "Содержание" экземпляр "Сайт 1" (типичная мультидоменная CMS). Можно создавать зоны без привязки к доменам, а только к папкам. Тогда на всех связных с системой доменах, при открытии адреса "/admin" (как пример) будет загружаться админка.

Зоны проходят проверку по IP-фильтру. Вы можете сделать так, чтобы один и тот же домен показывал разные сайты, если зайти на него из России и Украины (типичная CMS с поддержкой многоязычности). IP-фильтр системы может состоять из целого набора значений (тут и IP диапазоны, и указание городов или даже стран, согласно WHOIS написанию).

Итак, зона определена. Дальше система передаёт оставшуюся часть URL указанному в зоне экземпляру модуля.

2. Подбор части модуля

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

Сама по себе часть может иметь какой-то установленный адрес (например archive или help), но в большенстве случаев часть связана с таблицей. Например у модуля "Содержание" часть "Вывод страницы" связана с таблицей "Страницы". У которой есть поле URL, по которому и будет происходить разбор. При этом разбор будет производиться с учётом подстраниц.

Далее, определённая страница называется переменной COW (аббривиатура к сожалению забыта мною), которая указана в коде части "Вывод страницы".

3. Усложнения

У нашей страницы может быть поле "Модуль", которое в свою очередь ведёт на некий экземпляр какого-либо модуля. Для его вывода часть "Вывод страницы" использует код [cow.module.auto], который передаст управление и оставшуюся часть URL следующему модулю (например, это могут быть новости или фотогалерея).

Также, у страницы может быть подтаблица из другого модуля "Комментарии". Для отображение этой подтаблицы, мы можем вызвать этот самый модуль ([cow.comments.md.auto]), который в свою очередь также получит для разбора оставшуюся часть URL.

Надеюсь, моему дорогому читателю стало ясно, что вложенность модулей друг в друга может быть бесконечной. Также, как и вложенность строк.
Чисто теоретически, вы можете сделать такую систему, в которой содержание будет отсылать нас к новости, а новость к содержанию (только уже к своим страницам) и т.д.

В настройках "отлова" URL в части модуля, вы можете указывать такие замудрёные параметры, как:

1. Игнорировать строку-родителя при разборе. Разбор будет идти до самого последнего досягаемого элемента, и уже только тогда запустится часть. Например, имея адрес /Чайники/Россия/Самовар1Ф, часть сразу начнёт разбор с Самовара, пропуская и категории товара и страну производителя.

2. Включать в разбор строки из подчинённых таблиц. Я обычно для подтаблиц, использую отдельные части, которые наследуют разбор за текущими. А если подтаблица из другого модуля, то тем более - использую часть того модуля, откуда ко мне пришла эта таблица

3. Запускать в случае, если под URL не подошла ни одна часть. Банальный обработчик 404 ошибки. Теперь будет где написать "Страница не найдена" :) Кроме того, подобного эффекта можно добиться, если строке (чья таблица участвует в URL-разборе) присвоить адрес "-" (минус). Но возникают проблеммы, когда у таблицы одни строки влагаются в другие. Т.е. например адрес /абракадабра будет пойман, как не существующий, а вот адрес /news/абракадабра просто откроет перед нами страницу news.

Вот в принципе и всё, что я хотел рассказать о работе с URL. Рекомендую изучить примеры, которые показаны на рисунке в самом начале данного поста. Данные примеры представлены только для ознакомления. Автор ни в коем разе не думает, что такие решения (которые указаны в примерах) являлись бы оптимальными. Они придуманы только для демонстрации возможностей.

Вопрос о выборе конструктора модулей

2011-10-21T16:50:00.000-07:00

Я до сих пор не могу определиться с концепцей конструктора. Скорее всего это будет смесь между WYSIWYM-ом и WYSIWYG-ом. Т.е. каркас будет строиться из простых элементов (text area) и связей между ними, а внутри каждого элемента будет возможность перехода в визуальный редактор CKEditor, в который будет интегрирован селектор значений (о котором я уже кажется писал в предыдущем посте про конструктор/редактор).

Можно было бы и не париться - сделать всё на базе CKEditor-а, заранее снабдив его дополнительными кнопками. Но мы имеем дело с жёсткой структурой, в которой существуют IF и TREE элементы, делящие шаблон на части. Основная мыслительная деятельность направлена именно на то, чтобы узнать - а нужно ли разделять код модуля на элементы IF, ELSE, TREE, AFTER или же достаточно тот же IF интегрировать в CKEditor (как это реализовано у Ucoz-а).

В некоторых случаях вообще вредно бить контент на элементы. Особенно когда мы имеем дело с короткими выпадами вроде <img src="[if x==1]1.jpg[else]2.jpg[/if]">. Понятно, что ради какой-то мелочёвки создавать дополнительные поля (отдельно под 1.jpg и отдельно под 2.jpg) это не очень правильно. Но если мы имеем дело с длинным участком кода, то его разбитие намного упростит логику приложения.

Тем более я не представляю возможным на базе CKEditor-а делать сделать связку из трёх картинок (IF ELSE /IF) и текста внутри них, особенно если будут ещё и под-IFы. Т.е. я догадываюсь о механизмах парсинга кода, которые будут стоять за подобной интеграцией, но намного проще будет сделать разбивку на элементы.

Как будет происходить создание вывода (приложения/шаблона) модуля? Вначале перед нами пустое поле, которое мы можем редактировать в режиме HTML и CKeditor. CKeditor используется только для операций с вёрсткой и оформлением участка. Переключившись в HTML мы имеем доступ к устновке IF-ов (условий) и TREE (циклов). Нажав на TREE текст делится на три текстовых поля. 1-ое поле вбирает в себя текст до курсора, 2-ое поле пустое и предназначено под нутро цикла TREE, оно немного сдвинуто вправо, чтобы была видна его вложенность, и 3-е поле отображает текст, который был после курсора. Если в этот момент был выделенный текст, то он попадает в 2-ое поле.

Таким образом, мы можем делить текст этими операторами сколько угодно раз. Разбивка в этом случае подобна дереву (в виду своей вложенности одного оператора в другой). Получается, что это дерево - своеобразный WYSIWYM, а содержание каждого отдельного элемента становится WYSIWYG-ом. Когда я заканчиваю редактирование элемента, я могу выбрать как он будет отображаться - в виде HTML+E5 кода, либо в визуальном виде (отображается он будет уже не в CKEditor-е, а в DIV-е).

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

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

Сегодня я узнал о ещё одной хорошей CMS

2011-10-18T10:25:00.000-07:00

Её имя - ProcessWire 2. На главной странице их сайта (http://processwire.com/) расположено видео, которое демонстрирует основные возможности. В чём-то есть схожесть с друпалом, в чём-то есть схожесть с Е5.

Что мы имеем? По сути это таже модель MVC, но модель данных составляется динамически, в зависимости от ситуации. То, что в Е5 называется таблицей данных, в ProcessWire зовётся шаблоном.

Работа с системой по сути сводится к разработке шаблонов данных (состоящих из комбинации различных полей), а затем использование этих шаблонов в произвольной структуре. Так, например родителем элемента "Новость", может быть элемент шаблона "Содержание", а потомком "Новости" опять же "Содержание" или "Комментарии". Т.е. каждая строка системы может иметь отличный тип от всех остальных строк.

В Е5 возможные дочерние элементы строк к рамках одной таблицы определены жёстко. Так, например, к новостям мы можем прикрепить дочерние элементы "Фотогалерея" и "Комментарии", которые будут присутствовать у всех новостей, в качестве подтаблиц. А в ProcessWire одна новость может иметь фотогалерею, другая - может иметь только комментарии.

С точки зрения юзабилити, ProcessWire превосходно адаптирован под пользователя. За минимум действий вы получите максимум результата. Админка работает как часы (чего не скажешь об админке Е5, в которой например не работает перетаскивание дочерних элементов к родительским, и вообще перемещение элементов иногда глючит).

Рассмотрим типичную задачу - сделать сайт-каталог Небоскрёбов (демо-сайт ProcessWire 2).

Реализация на ProcessWire:

Создаём шаблон "Город" (название + описание)
Создаём шаблон "Архитектор" (название + описание)
Создаём шаблон "Небоскрёб" (название + описание + координаты + город + архитекторы)
Создаём элементов шаблона "Архитекторы" , например "Девид Магеланос", "Санчо Кэсседи" и "Ариель Четландес"
Создаём нексолько элементов шаблона "Города", например "Нью Йорк", "Неаполь", "Сан Франциско" и "Милан"
Создаём под элементом "Нью Йорк" несколько подэлементов шаблона "Небоскрёб" и связываем их с имеющимися архитекторами. При этом связь осуществляется путём добавления нового поля "Архитектор", которе имеет тип "Ссылка на множество страниц", и родителя "Архитекторы". Решенее мягко говоря не гибкое и не самое лучшее.

Т.е. на протяжении всей работы мы имеем дело с одним деревом, в котором есть всё. Для экономии загрузки, авторы подгружают разделы Ajax-ом.

Также не ясно, на чём конкретно пишутся шаблоны вывода всего этого содержания. За время копания в админке, мне так и не удалось это выяснить. Судя по всему, есть некоторое внутреннее API, которое привязывается через всё тотже старый добрый Smarty :)

Реализация на E5

Первые 3 пункта полностью совпадают. Для ускорения этих операций, в Е5 предусмотрены не только шаблоны полей, но и шаблоны таблиц.

Создаём таблицу "Город"
Создаём таблицу "Архитектор"
Создаём таблицу "Небоскрёб"
привязываем поля "Архитекторы" и "Город" к соответствующим таблицам
"Архитекторы" будет иметь возможность множественного выбора, "Город" - еденичного
Как альтернатива - мы можем сделать таблицу "Небоскрёб" подтаблицей "Городов" (можно сказать, что это будет аналог ProcessWire-вскового решения),
Создаём шаблоны вывода городов, архитекторов и небоскрёбов, делаем необходимые настройки, для автоматической генерации и распознавания URL
Заполняем таблицу Архитекторов и Городов
Заполняем таблицу Небоскрёбов, привязывая её к Архитекторам и Городам (в Е5 есть компонент, который позволяет добавлять Архитекторов и Города "не лету")

Лично мне, реализация на Е5 кажется более прозрачной и простой. Многие скажут, что такое решение ограничивает пользователя и в этом есть доля правды. В Е5 я не могу присоеденить подстроку "Небоскрёб" прямо в таблице "Город", для этого мне придётся для ВСЕХ городов делать подтаблицу "Небоскрёб". Таким образом, если я буду работать с таблицей данных, каждая строка которых будет иметь уникальное предназначение (одна строка - небоскрёб, вторая - новость), то у меня будет гигантский список пустых подтаблиц напротив каждой строки.

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

Улучшения внутренних функций и новые планы

2011-10-17T21:34:00.000-07:00

Работа со строками

Для фильтрации строк использовался оператор [filter], который выполнял операции [if] над всеми входящими строками, а результат записывал в виде переменной, или в виде "субстрок" таблицы данных. От этого подхода решено было уйти в пользу оператора .SEL. Также и от сортировки [order] перешли к более удобным операторам .DESC, .ASC и .RAND

Если вы ярый изобретатель CMS, то читайте это сообщение дальше.

Если мы фильтруем многоуровневую таблицу данных, то для фильтрации дочерних элементов в [filter] устанавливался знак ^ перед перебираемыми данными. В .SEL эта возможность отсутствовала до вчерашнего дня. Теперь по умолчанию .SEL использует глубинную фильтрацию и сортировку. Возможно, позже предётся вводить дополнительные команды для отключения глубинности просмотра.

Напомним разницу конструкций:

Конструкция Filter
[filter cex.articles.rows "active_rows" enable==1]
И далее мы имеем доступ к отобранным строкам через cex.articles.active_rows

Конструкция Sel
[active_rows=cex.articles.rows.sel(enable==1)]
Доступ к элементам через [$active_rows]

Доработаны операторы NEXT и PREV

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

Сейчас операторы NEXT работают с параметром X, и находят следующий от X элемент.
Например: cex.articles.rows.next(Номер статьи)

Это не очень удобно, хотябы потому, что возможны такие варианты:
cex.articles.rows.next(cex.articles.rows.sel(title=="1 новость").first)

Вместо логичного cex.articles.rows.sel(title=="1 новость").first.next (и вообще если элемент поиска 1, то зачем first?)

По этому я планирую ввести NEXT и FIRST также и в обработчике строки. При этом их значения будут равны их значению в админке (в отличие от предыдущего NEXT-а, где показывается следующий элемент в зависимости от любой входящей выборки).

Работа пользователя с собственными строками

Для этого планируется несколько решений.

1. Usel. Оператор, который выполняется над любым набором строк - выявляя только те, в которых присутствует поле "пользователь" с текущим пользователем. Usel("user") указывает на конкретный столбец, с которым нужно сравнивать пользователя (если у таблицы более 1 поля "пользователь"). Usel2 - выбирает те строки, которые непосредственно создал пользователь.
Например: cex.articles.rows.usel

2. User.module.ex.table. Данная конструкция довольно громоздкая из-за необходимости указывать модуль, его экземпляр и таблицу (в предыдущем способе достаточно указать экземпляр и таблицу. Скорее всего будут упращения в виде user.cex.table или user.cm.ex.table

Новые виды полей

"Группы" - ссылка на одну из групп пользователей, или на целый набор групп. Таким образом, мы сможем добавлять поле "Разрешить доступ для групп" в таблицу "Содержание" сайта. Далее, для каждой отдельной страницы мы сможем указывать для каких групп возможен доступ (если не отмечено - то доступ соответственно имеют все группы).

Поле "Пользователь" возможно получит множественное значение.

Изменения в дизайне

2011-10-10T19:07:00.000-07:00

Наконец начались сдвиги по части дизайна системы. Огорчает то, что все плюшки значительно замедляют скорость работы. Так например строки в системе можно сортировать методом Drag&Drop, засчёт подключения компонента tableDnD. Однако не всё так просто. В наших данных есть не только таблицы, но и связные строки-подтаблицы. Чудом, но нам удолось реализовать перемещение связных строк синхронно друг с другом. Но косяки бывают если два раздела с подразделами начинать перемещать рядом друг с другом.

Кроме этого, пользователи смогут видеть владельца строки данных и даже менять его.

Итак, за это время сделано:

Сортировка строк методом Drag&Drop
Замена большенства функций иконками
Обзор и изменение владельца строки
Изменён механизм развёртки подстрок
Переработан механизм выбора всех строк (теперь работает и в IE)
Строки, отмеченные галочкой, а также неактивные строки теперь выделяются на фоне остальных

Проблемма с авторским правом

2011-10-06T03:49:00.000-07:00

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

Иконки

Иконки я подбирал на сайте findicons.com. Если кто-то знает, можно ли свободно использовать иконки с этого сайта - пожалуйста сообщите. Т.к. авторов многих иконок попросту не найти, а они уже прижились в системе. Вроде бы большинство коллекций иконок просто требуют установки ссылки на них. Придётся либо перерисовывать все иконки, либо выпускать как есть. А затем, если авторы будут делать запросы, то в системе будут появляться ссылки на них.

Java-скрипты

Некоторые функции приходилось копировать из открытых источников (например аналог функции explode и т.д.). После того, как я в очередной раз скопировал очередной скрипт, заметил, что на автомате я копировал только скрипт, без комментариев выше него, в котором указывался автор. Авторов ява-скриптов найти проще (по части скрипта, вбив его в поисковик). Этим и придётся заняться по факту выпуска системы.

Flash, JQuery и Mootools плагины

В систему встроены разные фотогалереи (HighSlide, Milkbox, Shadowbox, Colorbox), карусели, ротаторы и прочие плюшки. У них авторы указаны в файлах скриптов, но нужно ли указывать их дополнительно в системе? Ещё есть флеш-компоненты для загрузки изображений, отображения слайдшоу и перелистывающийся журнал.

Может подойдёт такой вариант - саму систему сделать пустой, а подобные плагины предлагать подгружать с "левых" серверов обновлений.

Может я заморачиваюсь? Ведь система будет бесплатной.

Приступаем к созданию редактора шаблонов

2011-10-04T12:57:00.000-07:00

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

Что из себя будет представлять редактор? Я ещё не решил что взять за основу. Либо это будет WYSIWYG CKeditor (с которым у меня очень большой опыт общения, по сути я разобрал его вдоль и поперёк ещё тогда, когда он был FCKEditor-ом), либо придётся писать свой редактор.

Писать свой редактор означает для меня +3 месяца к разработке системы, либо придётся ограничиваться базовым функционалом (жирность, выравнивание, ссылки, цвет текста). Вставка таблиц и изображений уже представляет определённые трудности.

Всего четыре кнопки

На самом деле кнопок будет больше, но начнём мы с четырёх:

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

Для того, чтобы прочитать ещё 2 тонны текста, нажмите на ссылку "Дальше".

Как мы видим, у нас есть два типа элементов: X - данные, Y - условие.
Условие Y состоит в свою очередь из данных X (например, Y будет правдой, если X1==X2 или X3<X4).

При этом X может быть либо значением, либо набором значений. Значение используется в одних случаях (например, в вставке значения), а массив (набор элементов) в другом (например в переборе).

Таким образом, редактирование шаблона сводится к написанию самого текста (если он нужен), определению HTML вёрстки (которую можно сделать теми же средствами визуального редактора) и вставке в нужных местах Значений, Переборов, Условий и Компонентов.

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

Из чего выбирать переменные? Это будет зависить от того, чей шаблон вы редактируете. Если это часть модуля, то перед вами будут данные всех таблиц этого модуля (пример рассмотрим далее) и этой части. А если вы будете редактировать шаблон компонента, то перед вами будут только переменные этого компонента.

В случае, если мы редактируем часть модуля (про устройства модулей поговорим позднее), перед нами будет набор из следующих элементов:

Переменные строки, которая была обнаружена при URL-разборе (про URL разбор и ЧПУ также поговорим в другой раз).

Пример: в модуле "Новости" есть таблица "Метки новостей", эта таблица связана с частью "Содержимое метки". В случае, если пользователь заходит по адресу /news/metka1, нас направляют на часть вывода метки и выводится будет строка, с URL "metka1". Таким образом, в части выводе метки у нас будут доступны переменные таблицы "Метки новостей" (например "Название метки", "Описание метки").
Переменные текущей перебираемой строки (если мы вызвали диалог в теле перебора)
Набор строк таблиц, которые находятся в модуле (например "Все новости" или "Активные новости")
Переменные: созданные по мере выполнения части, переменные самой части, переменные экземпляра модуля или глобальные переменные.

Рассмотрим тривиальную задачу: в модуле Новости нам нужно сделать часть, которая будет выводить все новости. У нас уже создана таблица новостей, с полями: "Анонс", "Дата", "URL".
Для этого нажимаем "Вставить перебор" и в нём выбираем таблицу "Новости". Далее, в теле этого цикла нажимаем "Вставить значение", выбираем "Значение текущего перебора" и в нём "Анонс", "Дата" и "URL" соответственно.

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

Модификаторы имеют тип входных данных (массив или значение), тип выходных данных (массив или значение) и набор переменные (X или Y, т.е. значение/массив значений или условие). При указании переменной модификатора, перед нами открывается такое же окно поиска Значения, поверх текущего окна - и так до бесконечности. Ествественно модификаторы могут накладываться друг на друга соответсвенно своим входным и выходным данным. Диалог поиска значений невозможно закрыть до тех пор, пока вы не приведёте данные в нужный вид (значение или массив). Как уже писалось выше, это зависит от того, для чего вы используете эти данные - в перебор принимаются только массивы.

Модификаторы и их свойства жёстко привязаны к ядру системы.

Компоненты системы позволят облегчить решение большинства задач. Уже сейчас имеются компоненты для постраничной разбивки, генерации форм, работы с Ajax, массовой загрузки фотографий. Визуальный редактор также является компонентом системы. Сами по себе эти элементы делятся на: отображения, компоненты, функции и формы.

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

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

Пример вывода древовидного меню:

--------------------------------------------------------------------
[tree cex.pages.rows]
<div style="padding-left: [10*step]px"> - <a href="[cur.wayback3]">[cur.title]</a></div>
[/tree]
--------------------------------------------------------------------

tree - перебор

cex - текущий экземпляр модуля

pages.rows - активные страницы сайта

step - текущий уровень вложенности цикла

cur - текущий элемент цикла (страница сайта)

title - заголовок страницы
wayback3 - возвращает значения URL-полей, начиная с самой верхней страницы сайта (при многоуровневой структура), заканчивая текущей, которые объединены знаком "/", например: "about/company/employers"

Пару слов об экземплярности

2011-10-03T11:46:00.000-07:00

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

В прошлом сообщении я опубликовал схему доступа к данным системы. Глядя на неё, первым вопросом будет вопрос "АААА!!! Зачем всё так сложно???!!". А точнее "что такое экземпляр? зачем столько разных экземпляров? экземпляр модуля, экземпляр таблицы, связи между экземплярами, между строками и ещё между какими-то подтаблицами".

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

(если вы не готовы к МНОГА БУКОФ, то не идите по ссылке "дальше")

Экземпляр модуля.

Мы не будем брать в пример задачи, когда нам нужно уместить два сайта на одной системе. Для начала возьмём простую задачу - сделать две новостные ленты. Даже на сегодняшний день многие популярные движки не имеют такой возможности, а которые и имеют, то обычно ограничиваются поддержкой экземплярности лишь некоторых основных модулей (обычно это ленты статей и страниц сайта). Создание двух лент явдяется поддержкой экземплярности модулем "Новостные ленты".

В системе Е5 каждый модуль можно "экземплярить" сколько угодно раз. При этом экземпляр модуля не будет полной копией всего модуля. Экземплярность применяется только к данным. Структура и обработчики модуля остаются одними и теми же.

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

Экземпляр таблиц

Раз есть экземпляры модулей, значит нам понадобятся и экземпляры таблиц. Можно было бы просто делать в строках ссылку на экземпляр модуля, но тогда мы бы упустили некоторые важные решения (о них ниже).

Связка экземпляров таблиц с экземпляроми модулей

Эта идея пришла не сразу. Те герои, которые смогли дочитать до этого места наверняка сказали себе "всё, теперь я точно ничего не понимаю".

В чём суть? Допустим у нас в системе есть 5 новостных лент (5 экземпляров модуля "Новости"), при этом кроме таблицы "Новости" там также есть таблица "Подписчики". И вот тут загвоздка. Клиент хочет, чтобы у первых трёх лент были общие подписчики, а у всех остальных отдельные. Как реализовать такое? Именно по этому и были созданы экземпляры таблиц и их связи с экземплярами модулей. Таким образом, после создания требуемой заказчиком системы, мы получим: 5 экземпляров таблиц "новости", 3 экземпляра таблиц "подписчики". Первые три экземпляра модуля будут связаны поочерёдно с трёмя экземплярами таблицы "новости" и с одним экземпляром таблицы "подписчики", а каждый из следующих двух экземпляров будет связан с одним экземпляром "новости" и "подписчиков". Уф..... Надеюсь вы что-нибудь поняли.

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

Связи строк

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

Общий смысл - вы можете создать дерево разделов на сайте, например раздел "О компании" и к нему куча подразделов - отдельные страницы для всех сотрудников, обширная история и т.д. Затем такую же структуру вам нужно продублировать в закрытом разделе. Что делать? Просто нажимаете "подчинить" рядом со строкой, и выбираете ей нового родителя. Вуаля! Теперь информация проецируется сразу на два раздела. При этом, изменив её в одном месте, она меняется во всех. Подобное устройство строк данных доступно в некоторых современных CMS.

Экземпляр системы (зоны)

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

В последнее время стало модно использовать мультидоменные CMS, т.е. такие системы управления, которые позволяют работать сразу с несколькими доменами (при этом каждый новый домен может быть отдельным сайтом, а сама система размещается на одном веб-сервере).

В системе Е5 можно создавать неограниченное количество зон. Каждая зона может быть присоединена либо к домену (www.test.ru), либо к папке внутри домена (www.test.ru/admin), либо к папке во всех доменах (/admin).

Зона может нескольких типов:

Ссылаться на экземпляр модуля, который будет обрабатывать все её запросы
Вести в админку
Ссылаться на сервер-обновлений
Ссылаться на другую зону (зона-ярлык)

Таким образом, вы можете прикрепить к системе неограниченное количество доменов, каждый из которых будет отдельным сайтом, некоторые домены могут быть слиты в один сайт, и на всех них папка /adm или /admin будет открывать доступ в админку.

Благодаря продвинутой системе доступов, в Е5 можно создать большое количество разнообразных закрытых зон для различных групп пользователей, или даже закрытых сайтов. Например, для одних пользователей вход в админку будет доступен по адресу /admin, а для других - по адресу /manager. Одни пользователи смогут заходить на сайт www.test.ru, а другие не смогут. Кроме того, можно сделать две зоны на один домен или на одну папку, и одним пользователям показывать один сайт, а другим пользователям показывать другой сайт, по тому же адресу.

В настройке зон есть специальный пункт "IP-конфигурация", который позволяет делать зону доступной (или недоступной). для:

Определённого IP-адреса
Диапозона адресов
Пользователей определённого города или страны (для этого используется определение по базе WHOIS, одного известного ресурса)

Эти доступы можно комбинировать между собой. Таким образом, вы можете сделать сайт www.test.ru на русском языке, для посетителей из России и Украины, и на английском, для зарубежных гостей. При этом этот сайт будет совсем недоступен для всех жителей Москвы, но будет доступен для вашего IP-адреса, даже если вы будете в Москве.

Зоны поддерживают распознование кириллических доменов (за это отдельное спасибо разработчику модуля дешифратора XN доменов, о нём я писал в предыдущих постах, правда пришлось допиливать этот модуль, чтобы он корректно работал и на PHP5 и на PHP4).

Кстати экземплярность системы не достягается засчёт зон. Зоны это всего-лишь ссылки на экземпляры модуля. А вот уже засчёт них и достягается экземплярность системы.

Надеюсь в следующий раз я напишу в три раза меньше текста и в два раза понятней.

Структура данных

2011-10-03T08:50:00.000-07:00

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

Одной из идей системы было то, что любое изменение делается напрямую из админки, и пользователь никак не затрагивает MySQL или файлы на сервере. А это означает, что структура баз данных не должна зависеть от сложности проекта и изменение проекта (добавление модулей, компонентов, данных) никак не должны сказываться на структуре. Т.е. нам нужна максимально ёмкая структура.

Стандартный подход к данным

Все мы привыкли к структуре, в которой таблица данных MySQL привязывается к модулю (или несколько таблиц). В каждой таблице есть набор столбцов (переменных модуля), и набор строк, в которых и хранится вся информация модуля.

Такой способ хранения данных в MySQL универсален и позволяет создавать любые модули, но есть некоторые моменты, ограничивающие её удобства:
- Если мы хотим добавить, например поле "Город" в таблице комментариев, то необходимо добавлять столбец Town через MySQL (некоторые CMS предоставляют специальное API), затем редактировать административный раздел, в котором показываются комментарии и (самое главное) - редактировать шаблоны вывода комментариев и формы его добавления (если шаблонов нет, то напрямую в исполняемом .php файле)
- Связь между таблицами нужно устанавливать вручную с помощью специальных полей-ссылок
- Многоуровневую структуру строк таблицы можно организовать только прикрутив специальное поле, которое будет означать владельца строки

Все эти пункты значительно утяжеляют разработку и модификацию модулей для CMS, усложняют SQL запросы.

Для CMS-систем одним из важных требований является возможность обновления существующих модулей. Обновление может подразумевать добавление/удаление таблиц из модуля, и добавление/модификацию/удаления столбцов таблицы. Тем самым, общепринятая структура хранений данных в MySQL делает обновление модулей чрезвычайно сложной операцией. Например, обновление осуществляется не только заменой нужных .php файлов, но также загрузкой и запуском специального файла, который производит необходимые действия с базой данных.

Виртуализация данных

Суть виртуализации заключается в том, что структура, которую видит пользователь на сайте или в админке, отличается от её представления в СУБД MySQL.

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

Модули
Таблицы модулей
Столбцы таблиц
Строки таблиц
Значение столбцов строк

Кроме этого, существуют дополнительные таблицы, которые обеспечивают связь, между таблицами (подчинение таблиц), строками (у одной и той же строки может быть несколько строк-владельцев) и экземплярами (про экземплярность поговорим позднее). Ещё есть специальные таблицы, отвечающие за разграничение прав доступа (пользователи, группы, права).

Сейчас система использует 19 таблиц. Из них 1 совсем бесполезная (используется для внутренней почты между пользователями системы).

Плюсы виртуализации

Работа с расширением модулей никак не затрагивает структуру БД
Внутринние связи между разными данными модулей поддерживает ядро системы (т.е. для реализации сложной структуры данных достаточно работать с админкой) - многоуровневость строк, экземплярность модулей, связи между строками и таблицами и т.д.
Не будет необходимости наделять одним и тем же (уже имеющимся в арсенале) функционалом разные модули. В Е5 одно и тоже решение можно применять к разным модулям, таблицам и данным.
Улучшение CMS (наделение её ещё большим функционалом) будет использоваться сразу всеми модулями и всеми данными, при этом их структура останется прежней (например, совсем недавно мы ввели систему доступов к данным, которая стала доступна для всех имеющихся модулей, при этом мы абсолютно не затрагивали структуру этих модулей).
Нет необходимости создавать дополнительные таблицы для новых модулей, а также для дополнительных экземпляров системы или экземпляра модуля.

Минусы виртуализации

Доступ к данным из PHP возможен только через API системы, либо через специальный язык шаблонов (в принципе, этим страдают многие CMS, у которых нет виртуализации данных, как таковой)
Решение: использование удобного визуального конструктора шаблонов, который сведёт на нет необходимость использования PHP. Уже сейчас язык шаблонов насчитывает порядка 300 комманд.
В конечном итоге, все данные размещаются в фиксированном количестве таблиц, из-за чего эти таблицы раздуваются до очень больших размеров.
Решение: в Е5 все таблицы имеют необходимые индексные поля, которые снижают нагрузку на БД, связанную с их объёмом. Планируется разделять таблицы, при существенном их увеличении. Также планируется вводить поддержку установки системы сразу на нескольких серверах, для оптимизации работы (для очень крупных проектов).
Увеличение нагрузки на сервер. Виртуализация добавляет промежуточные этапы, между запросом пользователя и непосредственному доступу к данным. Преобразование физической структуры данных к логической занимает некоторое дополнительное время, чего не происходит в обычных CMS, использующих прямую работу с MySQL.

Можно резюмировать: виртуализация данных имеет место быть при наличии правильного ядра системы, которое обеспечит максимальное удобство и скорость выполнения всех необходимых операций с данными. А также, при наличии правильного языка шаблонов (а ещё лучше - визуального конструктора шаблонов), который удовлетворял бы все современные нужды веб-разработчика.

Так выглядит структура данных в Е5 (для просмотра нажмине на миниатюру):

Схема доступа к данным:

Что нового сегодня?

2011-10-02T15:27:00.000-07:00

1. Значительно ускорена работа с правами доступа. А именно - ускорена отправка формы на сервер. Если раньше на сервер отправлялись тысячи кнопок по отдельности, то теперь они вначале компилируются в одно текстовое поле, и уже оно отправляется. Перекладываем нагрузки с сервера на клиента.

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

Правда его пришлось перекомпилировать (благо автор предоставил исходный код), и теперь в нём есть русский язык и поддержка выставления произвольной ширины и высоты. Этот плагин экономит просто кучу времени. Мне часто приходится грузить сотни мегабайтов на сервер. Правда при одновременной обработки 20 фотографий (каждая по 5мбайт), флеш начинает сжирать до 2гб (!!) оперативной памяти.

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

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

Конфликт решён

2011-10-02T10:32:00.000-07:00

Больше пришлось переживать :) Конечно не все так гладко, как хотелось бы, но ошибка устранилась. Правда магия в коде только увеличилась, но теперь всё работает.

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

Изначально код выглядел так:

//Доступы по умолчанию

$rules=load_perms(0,0,0,$rules); // Загрузка доступов для всех модулей
$rules=load_perms(0,1,0,$rules,1); // Перекрывание доступов конкретных модулей

//Доступы для групп

foreach($user->group AS $gr){
$rules=load_perms($gr,0,0,$rules); //Загрузка
$rules=load_perms($gr,1,0,$rules,1); //Перекрывание *

}

* - именно из-за этого перекрывания, перекрывались не доступы текущей перебираемой группы, а вообще все доступы

По этому мы добавили новую переменную rules2

foreach($user->group AS $gr){
$rules2=load_perms($gr,0,0,$rules);
$rules2=load_perms($gr,1,0,$rules2,1); //перекрываются не все доступы, а только текущей группы
$rules=merge_perm2($rules,$rules2); //функция сливания привелегий
}

Серьёзный конфликт доступов

2011-10-02T09:04:00.000-07:00

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

В чём его суть? Допустим у нас есть две группы пользователей. Одним всё разрешено, а другим всё запрещено. Теперь мы добавляем одного и того же пользователя в обе эти группы. По нашим правилам доступы должны складываться в пользу "Разрешить", но увы мы видим запрет для пользователя.

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

Хотелось сегодня посвятить день разработке визуального редактора шаблонов, но к сожалению предётся возиться с системой доступов. Надеюсь оно того стоит.

Вести с полей

2011-10-01T10:40:00.000-07:00

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

Что же осталось доработать?

Визуальный редактор для языка шаблонов
Дизайн административного кабинета
Шаблоны таблиц
Обновление модулей и компонентов (сейчас доступна только их загрузка)
Статистика посещаемости
Сортировка и фильтрация строк в админке
Правильная обработка математических и логических выражений
Обход CRON-а (скорее всего будет свой сервер для запуска задач по расписанию), чтобы избавить пользователей от мороки настройки CRON-а

И ещё список задач на будущее:

Возможность отката действий (отмена удаления документа)
Хранение разных версий документа (строки)
Групповая модерация документа (документооборот)
Сортировка строк методом drag&drop

Что заимствовано из готовых решений:

Декодер доменных имён XN (позволяет без проблем работать, например, с .рф доменами).
Автор: Matthias Sommerfeld
Визуальный редактор CKEditor
Автор: Frederico Knabben
Файловый редактор elFinder (с поддержкой прав доступа к папкам и файлам, интегрирован с CKEditor, открывается не в новом окне, а в текущем)
Автор: Dmitry "dio" Levashov, Troex Nevelin, Valentin Razumnyh
Массовый загрузчик изображений imgUploadv25 c сжатием на стороне клиента
Автор: Ady Levy

Ну и естественно используется JQuery. Кстати пункты 2 и 3 опциональны, и являются расширениями системы (компонентами), которые загружаются отдельно. Все эти решения распространяются под свободными лицензиями GPL и BSD.

Приветствие и введение

2011-10-01T08:06:00.000-07:00

Добро пожаловать в блог разработчика CMS E5. Здесь я буду стараться рассказывать о ходе разработки этой CMS. Система разрабатывается уже более года, а идеи для разработки назревали с 2006 года. Этот блог немного запоздал и в первых постах я постараюсь рассказать обо всех уже пройденных этапах.

Для тех кто не знает: CMS - Система управления содержанием (content managment system). Применяется для управления веб-сайтами (редактирование страниц, добавление новостей и т.д.) без прибегания к помощи программистов. Т.е. основной задачей рядовой CMS является предоставление возможности поддерживать свой сайт обычными офисными сотрудниками.

Система E5 будет полностью бесплатной. Все компоненты и модули можно будет бесплатно загрузить с сервера-обновлений. Кроме того, пользователи могут организовывать свои серверы-обновлений, делать свои редакции системы и писать свои модули.

Что же за идеи сподвигли меня заняться написанием CMS? Идеи эти не новы и посещали, пожалуй, всех программистов, которые имели дело с разработкой сайтов. Суть их сводится к создании системы, способной конструировать и модифицировать модули. Настолько простой, чтобы ей могли пользоваться обычные офисные сотрудники (без знания PHP, MySQL и т.д.).

Почему же не воспользоваться уже существующей системой? В Drupal, 1C-Bitrix, Umi-cms и CMS.Builder уже реализован конструктор модулей. Но эти конструкторы в конечном итоге заставляют нас переходить на всё тот же PHP, который, ко всему прочему, оказывается ещё и жёстко привязанным к ядру системы (работа с модулями осуществляется через API системы).

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

Зачем нужен конструктор модулей? Ведь можно обойтись стандартными модулями. Ведь так?
Не так :) Каждый пятый сайт обладает своим уникальным функционалом, которого нет в стандартных движках. Особенно это актуально, если вы работаете в серьёзной веб-студии или на госзаказ. Более того - если вы договорились с заказчиком о реализации сайта на стандартном движке (скажем жумла или вордпресс), то в процессе разработки могут всплыть требования, которые этот движок удовлетворить не сможет (например добавление меток к комментариям).

Если мы затронем модуль интернет-магазинов, то даже на платных платформах дела обстоят очень плохо. Каждый, кто имел дело с системами ShopScript, знает чего стоит разобраться в движке системы (там проблеммой является даже банальный поиск файлов, в которых лежит нужный код).

Есть интересный факт - подавляющее число веб-студий (особенно профессиональные) владеют собственной CMS. Но зачем она им, ведь в мире столько готовых решений? Именно за тем, что эти решения не подходят в некоторых проектах (как правило самых дорогих и основных). Но и конструктор модулей веб-студии не нужен, потому что за это у них отвечает веб-программист. Это означает, что любое изменение в системе обойдётся клиентам в кругленькую сумму.

Конструктор модулей - альтернатива веб-программисту? Зная спектр задач, с которыми приходится сталкиваться программисту, мы все дружно скажем: "Нееет! Это детская игрушка, которая создаст видимость гибкости системы". В следующих постах я подробней расскажу, какие задачи может решать контсруктор модулей в E5.

Почему у меня родилась эта идея? Есть такие люди, которые всё всегда хотят привести к какой-то системе, и по максимуму автоматизировать все рутинные процессы. Мне часто приходилось делать однообразную работу для сайтов и я всегда мечтал оптимизировать эти процессы. В детстве я писал собственную СУБД и этот опыт пригодился при написании одного портала с каталогом компаний. Особенностью портала был глубинный поиск компаний по критериям, и в каждом разделе была своя структура критериев. По сути, каждая карточка была своеобразным сайтом, а раздел - модулем. Этот проект дал существенный толчок к осуществлению этой нереальной идеи конструктора модулей.

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

Конечно мне хочется думать, что моя система принесёт небольшой вклад в развитие интернета, но я не питаю иллюзий насчёт неё. Пока это просто хорошее средство реализации собственных проектов. Да - я уже делаю сайты на этой системе (реализовано 38 проектов, рекордное время изготовления сайта - 1 час, с учётом рисования дизайна, его вёрстки и установки).

Некоторые выборочные скриншоты (тестовый дизайн админки)

Страница входа

Настройка доступов

Главная страница модуля