Элементы ядра

Итак, почему основной код SKY таков какой он представлен здесь? Хорош ли он или плох? На этот вопрос верный ответ может дать только время. Время жизни проекта SKY. после того как с ним познакомиться значительное количество программистов и твое личное время, дорогой читатель, которое ты посвятишь проекту SKY и сам проанализируешь то что имеется. В проекте прилагаются и будут прилагаться абсолютно все возможные усилия и средства, чтобы этот код был идеальным! Начнем сначала: должен ли быть идеальный код быть достаточно простым, чтобы им могли легко пользоваться подавляющее большинство веб-программистов, практически без прочтения документации и при этом быть очень эффективным, возможно ли это? Ответ на оба вопроса: да! Простой код, - это первое и самое главное правило разработок в SKY. Более того, идеальный код, априори, может быть только один и он ищется в проекте SKY.

Размышления при создании основного кода таковы: нам нужен будет код для повторного использования (1 файл - main/sky.php), который будет запускаться всегда, от любой точки входа. Он будет инициировать подключение к основной БД, будет включать функцию обертку sql() для осуществления запросов к БД, все запросы проходящие через эту функцию будут автоматически попадать в буфер трассировки. Нужна функция трассировки и собственный обработчик ошибок, который будет вызывать функцию трассировки с параметром "показать ошибку", нужен класс SKY, который будет содержать реестр данных, память конфигурационных данных, а также иметь другой полезный функционал. Файл main/sky.php назовем файлом первого крыла, так как он будет выполняться для всех точек входа.

Для точек входа front и admin создадим файл main/wings.php, он будет содержать стандартный повторно используемый код для пользовательских сессий, регистрации пользователей и прочий код, это код второго крыла, так, как он используется более чем для одной точки входа.

Также создадим файл main/front.php - этот файл будет использоваться только для одной точки входа - front, поэтому, это код третьего крыла, как и код в файле main/cron.php - для запуска из точки входа cron.

Основная система адресации

Запросы в админ часть:

http://mysite.net/adm?page

где /adm указывает на доступ в админ часть, a page на исполняемый файл в папке admin, т.е. admin/_page.php, в файле .htaccess запрос перенаправляется на index.php, из этого файла, в свою очередь вызывается роутер админки - admin/index.php. Запросы на фронтальную часть:

http://mysite.net/page?qq=ww

Таким образом если считать что универсальная адресация (наиболее гибкая) включает: протокол, доменное имя, адрес папки, файл и QS (query string, ключи со значениями, например ?qq=ww&rr=tt), то в основной системе адресации SKY. приложений запрещено использование части "адрес папки" (использования символа разграничения папок "/"), что позволяет в view-файлах использовать относительную адресацию к изображениям и прочим адресам, это значительно упрощает кодирование обращений, размер генерируемого HTML файла. Также становится возможным не создавать отдельный виртуальный сервер для каждого проекта, но создавать новые проекты просто в папке одного и того же виртуального сервера на рабочей станции разработчика (все SKY. приложения должны оставаться работоспособными при размещении их в папке виртуального сервера), например

http://virtual-server1.loc/project3/

Заметим здесь, ради интереса, что константа PATH (см. файл main/wings.php) будет в приведенном примере содержать /project3/.

В SKY. введены абстрактные переменные PAGE, PVAL, WHAT, WVAL, которые соответствуют частям запроса - первый ключ и значение, также и второй. Первая переменная определяет соответственно страницу, которая соответствует файлу-обработчику или контроллеру (для MVC).

AJAX функционал

Обычно чтобы выполнить запрос ajax, нужно сделать много формальных действий, поэтому чтобы их не делать (чтобы было просто), в SKY., в файле pub/wings.js введена функция ajax(..). При ее использовании не нужно писать адрес файла-обработчика, так как подставляется часть текущего адреса страницы (извлекается из document.location.href), т.е. (в случае MVC) обращение идет на "свой" контроллер, а указывается только псевдо-имя метода обработчика. В функции также предустановлено использование метода POST, так как намного чаще AJAX функционал требует отсутствие кеширования браузером, кроме того адрес формируемый для реального обращения к серверу включает стандартную часть для этого функционала - ключ AJAX:

http://mysite.net/index.php?AJAX=page&page=pval (pval - метод контроллера для MVC)
http://mysite.net/index.php?AJAX=adm&page=pval (ajax запрос в админ часть) http://mysite.net/index.php?_=adm&page=pval (обычный, не ajax запрос в админ часть выполняется MOD_REWRITE)

который устанавливает PHP константу AJAX в не нулевое значение, т.е. уже в повторно используемом коде первого крыла имеется информация о стандартном AJAX запросе, что позволяет, например, автоматически отключить LAYOUT для такого запроса, а трассировочные данные записать в БД (а не сделать вывод в STDOUT)

Буферизация STDOUT

Код PHP "echo 'z';" выводит условно в браузер один байт "z", но реально, практически никогда так не происходит, но вместо этого, происходит запись в системный буфер и только по достижении "нужной порции" данных, происходит реальная передача данных по сети. Буферизация STDOUT это фундаментальный механизм для значительного увеличения производительности при передачи данных по сети и нормального функционирования всех компьютеров и сетевых устройств. Наличие буферизации вытекает из той логики, что пакеты в сети имеют служебную информационную часть и часть полезной информации, и практически высокую производительность в сети удается достичь, когда кол-во полезной информации превосходит информационную часть (HEADER - шапка) в определенное количество раз, т.е. пакет не маленький (чтобы не передавать большое количество шапок) и небольшой (чтобы отправлять информацию приемнику с одной стороны как можно быстрее и с другой, легче было исправить ошибочный пакет не очень большой величины). С другой стороны, при передаче очень больших страниц, необходимо экономить память сервера, и для каждого клиента (которые параллельно подключились) может быть выделен небольшой объем памяти, по сравнению с объемом всей отдаваемой ему страницей. Таким образом фундаментальная логика построения современных сетей, определяет необходимость создания буферов для различных протоколов более верхнего уровня, например HTTP, кроме того, подчеркнем, что данный функционал связан с аппаратными частями сетей, существование которых потенциально более стабильно чем существование любого ПО. Таким образом буферизацию можно рассматривать как де-факто функционал, который не поддается сомнению.

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

Метки можно разделить на ожидающие значения, сервисные и функциональные. Использование буфера для сжатия страниц и смены кодировки - это скорее представляет функциональность меток. Примеры меток в SKY: ожидающая - представьте, что у нас есть метка %ERROR%, которая определена на всех страницах в самом верху центральной части страницы (чтобы было удобно видно) и если PHP не нашел ошибок в коде, то она заменяется пустой строкой, а если нашел, то в самом конце скрипта (чтобы собрать как можно больше ошибок) метка %ERROR% приобретает визуальное преставление об ошибках в самом удобном виде. Сервисные - метки могут представлять одним идентификатором, например %PHP_NEWS%, некоторый HTML блок данных, который может содержать метки внутри (рекурсия) и переставляя метку в разные части страниц можно легко реализовать сложные формы отображения блоков на сайте, такие метки предоставляют сервисное удобство. Функциональные - например %HTML_X_COUNTERS%, так как здесь метка имеет префикс _X_, то на компьютере разработчика (когда константа DEV не ноль), она вместо того чтобы отображать javascript код счетчиков, которые вызывают скрипты находящиеся на внешних ресурсах в Интернете, отображает просто DIV с атрибутом class="red_label" и именем метки, это позволяет разработчику без каких либо сложностей и специальных действий вести разработку сайта OFFLINE, без Интернета.

Метки также позволяют реализовать функционал "жесткого" кеширования, который может повысить эффективность кода, например, представьте такой код:

В приведенном примере метка %PHP_RIGHT% (опознанная регулярным выражением) активирует запуск кода PHP метки, чтобы получить отображение. Если метка %PHP_RIGHT% генерирует содержимое правой колонки сайта и сиюсекундная актуальность содержащегося в ней отображения не актуальна (как часто бывает), то это содержимое может быть закешировано и актуализироваться только раз в 5 минут, например. Полностью сгенерированная правая колонка, записывается в файл cache/right_col.html. Во время выполнения функции cache('right_col'), проверяется, если вышеуказанный файл свеж, то код PHP метки не выполняется вообще, а отображение берется из кеш-файла. Такое кеширование может отключать выполнение нескольких SQL запросов и PHP код который генерирует содержимое правой колонки вообще и значительно повысить эффективность кода сайта. В этом случае метка, кроме сервисного, приобретает также и функциональное значение.

Негативные моменты функционала меток: во-первых, полученные данные от пользователей сайта и свои собственные данные содержащие знак процентов % (которые могут быть интерпретированы как обрамление метки) необходимо не забывать преобразовывать к аналогичной HTML сущности - %, иначе может быть допущена атака связанная с генерацией ненужных меток либо могут быть допущены свои собственные ошибки, связанные с этим, поэтому в коде первого и второго крыла сделаны соответствующие коррекции, см. например, код main/sky.php, функция html(..).

Во-вторых, к сожалению, в PHP, функционал связанный с работой буферов STDOUT чрезвычайно неудачно реализован и запутан, вместо множества функций семейства ob_.. ob_get_clean, ob_end_flush и т.д., необходимо было сделать одну функцию ob_action с ключами-константами OB_FLUSH, OB_GET, OB_CLEAN, OB_END, а также OB_REPLACE (замена содержимого буфера без факта сброса или очистки), OB_CALLBACK - указание необходимости вызова функции обратного вызова, а также условный сброс, очистку и т.д., например, при достижении порции для сброса 4096 байт, вызывается функция обратного вызова и проверяет все ли метки ожидающие значения уже вычислены (остальные типы можно вычислить на текущем этапе), если "да" высылается сетевой пакет в браузер, если "нет" - продолжается буферизация, это позволило бы использовать мощности компьютера на 100% в этом аспекте. Также необходимо, чтобы первый уровень буферизации был виртуальным, т.е. при первом вызове функции ob_start() использовался системный буфер, и память специально для него не выделялась, а в функции обратного вызова буфер передавался по ссылке.

Многоязычные веб-приложения

Рассмотрим возможные типы многоязычных приложений.

MVC

Гениальность паттерна MVC проявляется в самом простом его варианте.

Черные ящики

Есть идея создать "черные ящики" в SKY. приложениях. Что это такое и каково их назначение? Ну, во-первых, это повторно используемый код, который будет храниться в ячейках БД приложений, который будет упакован (удалены пробельные символы) для повышения производительности. Такой код не будет "маячить" в файловой системе с кодом приложения и облегчать понимание структуры приложения для программиста, а исполняться такой код будет посредством eval(sql("+select ...")); или специальной функцией. Кроме того существует фактор способствующий к созданию "черных ящиков" в связи с тем, что существует множество примеров повторно используемого кода, который должен быть в приложении, но его нежелательно видеть в файловой системе на этапе разработки приложения для программистов, например код который анализирует какой тип устройства обратился к сайту - мобильное устройство с ограниченным экраном или рабочая станция с "большим" монитором. Код в этом примере содержит множество сравнений user-agent запроса (или/и еще других переменных) на определенные сигнатуры в определенной последовательности и был создан однажды кропотливым трудом (или регенерирован автоматически специальным алгоритмом) и нежелателен к просмотру программистом в текущем проекте, т.е. принято решение программистом использовать код "как есть" без возможных дальнейших его усовершенствований. Конечно, использование исполняемого кода хранящегося в БД создает дополнительные риски с точки зрения безопасности, но эта технология может применяться только (отдельная тема для обсуждения) в режиме DEBUG на рабочей станции разработчика! Программисты сами могут решать какой код "отправить" в черный ящик, а перед выгрузкой кода проекта на "продакшн" в агрессивную сеть удалять черные ящики (и всю систему их) с помощью специальной утилиты приложения DEV.SKY. Для организации такого процесса можно придумать формальную схему, алгоритм, который будет частью DEV.SKY. Черные ящики также могут храниться в базе кода Codebase на сервере SKY. (при условии доверия коду на сервере), что будет указывать на то, что данный код имеет свойство потенциально низкого внимания к коду в плане его усовершенствования ввиду определенных причин. Несмотря на "закрытость" кода, код может быть просмотрен и изменен в приложении DEV.SKY.

Адаптация сайтов для мобильных приложений

В связи с глобальным распространением мобильных устройств, в данное время, появилась необходимость быстрой адаптации сайтов к мобильным версиям. width="100%"

Инициализация и сброс приложений

Если папки с файлами веб-приложения не должны быть доступны для веб-сервера (например папка main), но находятся в "открытой зоне", обычно в такую папку записывают файл .htaccess (для веб-сервера apache) с содержимым: deny from all, что предотвращает доступ к папке средствами веб-сервера и некоторым образом гарантирует безопасность от постороннего доступа к файлам. Создание таких файлов не несет смыслового кода для функционирования приложений, а является чисто средством по обеспечению безопасности. Вообще, на основе абстрактной логики, имеет смысл (и реализовано в SKY. приложениях) сделать функционал INIT и RESET, а код поместить в файл main/debug.php. Этот функционал (и весь файл целиком) подключается только в режиме DEBUG приложения, т.е. только тогда, когда в файле main/conf.php константа DEBUG имеет не нулевое значение, когда приложение находится в отладочном режиме, а значит почти всегда только на рабочей станции разработчика и на продакшн не будет создавать абсолютно никаких дополнительных вычислительных затрат. Функционал INIT запускается всегда один лишь раз в жизни, после инсталляции любого приложения (записи Codebase с префиксом a:, например a:lite.sns, для функционала же RESET имеется кнопка в админ части любого приложения (который имеет админ часть). Файл admin/_main.php используется в админ части во всех приложениях. Создание файлов описанных выше (.htaccess), резонно делать через функционал INIT, чтобы не "засорять" код создания приложения в записи Codebase подобными формальными действиями. Подобно этой логике существует и другой функционал, в абстрактном смысле, который удобно отнести к стандартному функционалу INIT и RESET приложений SKY.