Концепия Визуальной Среды Программирования (WYCIWYC)
Изначально основой для создания концепции визуальной среды программирования (WYCIWYC - What You Click Is What You Code) послужило желание создать быстрый и удобный в управлении движок для создания веб-сайта на основе LAMP (Linux+Apache+MySQL+PHP). Однако после того, как первый прототип был написан и опробован в работе (на его основе уже можно было сделать простой сайт), мною было проведена дальнейшая разработка этой задачи, в результате чего была выработан теоретический механизм, получивший название Концепция Визуальной Среды Программирования.
Что такое WYCIWYC
Технически вебсайт представляет собой программу, которая выдаёт сетевым клиентам файлы гипертекстовой разметки HTML, а также файлы бинарных данных, например, изображения или zip-архивы, добавляя в начало передаваемых данных специальный текстовый заголовок вида:
Название-поля-1: Значение поля 1
Название-поля-2: Значение поля 2
...
Бинарные данные представляют собой бинарные данные, а вот файлы гипертекстовой разметки представляют собой текстовые файлы тегового формата:
<tag1 attr1="value" attr2="value" ...>
<tag2 attr1="value" ...>
<tag3 attr1="value" ... />
<tag4 attr1="value" ... />
...
</tag2>
<tag5 attr1="value" ... />
...
</tag1>
Вместо вложенных тегов может содержаться обычный текст.
Таким образом несложно представить гипертекст в качестве структуры блоков с параметрами, задающих теговые аттрибуты. Например теговая структура HTML-страницы на основе тегов <html>
, <head>
и <body>
выглядит в классов приблизительно следующим образом (диаграмма 1):
Представим эту информацию как данные на MySQL-сервере. Для её хранения нам потребуются 9 таблиц:
- BlockParams (Параметры блоков)
- BlockParamNames (Названия параметров блоков)
- BlockParamTypes (Типы параметров блоков)
- BlockParamTypeNames (Названия типов параметров блоков)
- Blocks (Блоки)
- BlockTypes (Типы блоков)
- BlockNames (Названия блоков)
- BlockTypeNames (Названия типов блоков)
- Paths (Пути к файлам)
Классовое представление этих 9 таблиц выглядит следующим образом (диаграмма 2):
Естественно, что возникает вопрос, зачем хранить названия в отдельных таблицах. Так следует поступить по той причине, что данные о названии требуются только на этапе разработки и отладки, а на этапе обработки данных, например, при выдаче страницы сервером пользователю, названия не нужны, поэтому если хранить их в отдельной таблице, ссылаясь на них по ROWID, то процесс обработки данных заметно ускоряется. Хотя при первом взгляде на диаграмму 1 кажется, что двух-трёх таблиц вполне достаточно.
Из диаграммы видно, что если каждой таблице сопоставить собственный класс, то в целом все эти классы окажутся классами трёх типов:
- Класс объекта
- Класс типа объекта
- Класс данных - таблица формата:
Таким образом несложно сделать следующее концептуальное обобщение: всё сущее есть объект, а класс объекта - это объект типа класс-объекта.
- ROWID
- VALUE
См далее
Автор: Андрей Шаройко <vanyamboe@gmail.com>