Проблема модульной веб-разработки — различия между версиями

Материал из YourcmcWiki
Перейти к: навигация, поиск
(Новая: В данный момент я (~~~~) создаю некую Новую Платформу для веб-разработки. Идея её, как всегда, частично ид...)
 
Строка 1: Строка 1:
−
В данный момент я ([[Участник:VitaliyFilippov|VitaliyFilippov]] 16:33, 12 июля 2009 (UTC)) создаю некую Новую Платформу для веб-разработки. Идея её, как всегда, частично идёт "от противного" - несмотря на то, что Платформа, Выросшая Из Vitaphoto, вполне жизнеспособна, юзабельна и даже содержит некоторые разумные идеи, она всё-таки неидеальна в использовании.
+
В данный момент я ([[Участник:VitaliyFilippov|VitaliyFilippov]] 16:33, 12 июля 2009 (UTC)) создаю некую Новую Платформу для веб-разработки. Идея её, как всегда, частично идёт «от противного» — несмотря на то, что Платформа, Выросшая Из Vitaphoto, вполне жизнеспособна, юзабельна и даже содержит некоторые разумные идеи, она всё-таки неидеальна в использовании.
  
 
== Цель ==
 
== Цель ==
  
−
Цель - добиться максимальных:
+
Цель — добиться максимальных:
  
 
# модульности
 
# модульности
Строка 14: Строка 14:
  
 
# Приложение делится на модули;
 
# Приложение делится на модули;
−
# Для вывода кода страниц используется [[VMX-Template|шаблонизатор]] своей разработки. Причём, он специально сделан максимально простым, дабы избежать анти-паттернов разработки, к которым подталкивает [[TemplateToolkit|Template::Toolkit]], а именно, к перемещению 50% логики в шаблоны. Примеры того, где так происходит - Bugzilla, Vsem.ru. Используется шаблонизатор, созданный когда-то по мотивам шаблонизатора phpBB2, о чём напоминает синтаксис. Умеет буквально 5 вещей: циклы, IF'ы, INCLUDE (включение другого шаблона), подстановки выражений в код, присваивания; Данные в шаблон передаются просто Perl-хешем;
+
# Для вывода кода страниц используется [[VMX-Template|шаблонизатор]] своей разработки. Причём, он специально сделан максимально простым, дабы избежать анти-паттернов разработки, к которым подталкивает [[TemplateToolkit|Template::Toolkit]], а именно, к перемещению 50 % логики в шаблоны. Примеры того, где так происходит — Bugzilla, Vsem.ru. Используется шаблонизатор, созданный когда-то по мотивам шаблонизатора phpBB2, о чём напоминает синтаксис. Умеет буквально 5 вещей: циклы, IF’ы, INCLUDE (включение другого шаблона), подстановки выражений в код, присваивания; Данные в шаблон передаются просто Perl-хешем;
 
# Конфигурация приложения представляет собой вложенный хеш, хранимый просто в виде Perl-кода;
 
# Конфигурация приложения представляет собой вложенный хеш, хранимый просто в виде Perl-кода;
  
−
Во-вторых, идеи, созданные "от противного" по отношению к старой платформе:
+
Во-вторых, идеи, созданные «от противного» по отношению к старой платформе:
  
 
# Модули теперь создаются по требованию, а не все сразу при старте приложения. Поэтому и modules_allow и modules_deny в конфигурации больше нет;
 
# Модули теперь создаются по требованию, а не все сразу при старте приложения. Поэтому и modules_allow и modules_deny в конфигурации больше нет;
 
# Обработчик приложения делает фактически только eval {} для отлова исключений и подключение директорий @INC. В старой платформе обработчик делал Много Чего, в результате появлялись жёсткие завязки на некоторые идеи:
 
# Обработчик приложения делает фактически только eval {} для отлова исключений и подключение директорий @INC. В старой платформе обработчик делал Много Чего, в результате появлялись жёсткие завязки на некоторые идеи:
−
## Нет виртхостов (хотя они реализуемы) - идея размещения нескольких сайтов в одной базе данных показала свою несостоятельность;
+
## Нет виртхостов (хотя они реализуемы) — идея размещения нескольких сайтов в одной базе данных показала свою несостоятельность;
−
## Нет завязки на вызов метода render() у модулей, т.е. методы обработки можно создавать любые по желанию;
+
## Нет завязки на вызов метода render() у модулей, то есть методы обработки можно создавать любые по желанию;
−
## Нет конфигурации "последовательностей модулей", т.е. вызовы разных модулей можно комбинировать в коде как душе угодно;
+
## Нет конфигурации «последовательностей модулей», то есть вызовы разных модулей можно комбинировать в коде как душе угодно;
−
## Нет хеша имён таблиц, сопоставляющего "реальные" таблицы "виртуальным";
+
## Нет хеша имён таблиц, сопоставляющего «реальные» таблицы «виртуальным»;
−
## Нет завязки на регулярные выражения в разборе URI, а точнее, нет вообще никакой завязки в разборе URI, как и самого стандартного разбора URI, кроме "страница?параметры";
+
## Нет завязки на регулярные выражения в разборе URI, а точнее, нет вообще никакой завязки в разборе URI, как и самого стандартного разбора URI, кроме «страница?параметры»;
 
## Нет завязки на обязательное соединение с БД;
 
## Нет завязки на обязательное соединение с БД;
 
# Вся функциональность, имевшая жёсткие завязки, теперь разнесена по модулям, и её можно как использовать, так и '''не''' использовать;
 
# Вся функциональность, имевшая жёсткие завязки, теперь разнесена по модулям, и её можно как использовать, так и '''не''' использовать;
−
# Стандартные библиотечные модули больше не предоставляют собой "готовых страниц" - каждый модуль теперь являет собой просто библиотеку функций, а функции, выводившие что-то в шаблон, теперь просто возвращают хеш, который можно подставлять, куда душе угодно;
+
# Стандартные библиотечные модули больше не предоставляют собой «готовых страниц» — каждый модуль теперь являет собой просто библиотеку функций, а функции, выводившие что-то в шаблон, теперь просто возвращают хеш, который можно подставлять, куда душе угодно;
  
 
И в-третьих, новые идеи:
 
И в-третьих, новые идеи:
  
 
# Все обращения к БД из библиотечных модулей теперь оборачиваются в функции и живут в Sway::db::, а рядом с ними лежат SQL дампы нужных им таблиц;
 
# Все обращения к БД из библиотечных модулей теперь оборачиваются в функции и живут в Sway::db::, а рядом с ними лежат SQL дампы нужных им таблиц;
−
# Аналогично обращениям к БД делаются абстракции других операций - иногда хранения (например сессий в кэше), иногда преобразования (например текста сообщений форума);
+
# Аналогично обращениям к БД делаются абстракции других операций — иногда хранения (например сессий в кэше), иногда преобразования (например текста сообщений форума);
 
# Версионирование БД;
 
# Версионирование БД;
 
# Поддержка Funq;
 
# Поддержка Funq;
−
# EmLog - простой интерфейс, этакий RSS с PUSH'ем для блогов, в качестве транспорта использующий Email.
+
# EmLog — простой интерфейс, этакий RSS с PUSH’ем для блогов, в качестве транспорта использующий Email.

Версия 19:33, 12 июля 2009

В данный момент я (VitaliyFilippov 16:33, 12 июля 2009 (UTC)) создаю некую Новую Платформу для веб-разработки. Идея её, как всегда, частично идёт «от противного» — несмотря на то, что Платформа, Выросшая Из Vitaphoto, вполне жизнеспособна, юзабельна и даже содержит некоторые разумные идеи, она всё-таки неидеальна в использовании.

Цель

Цель — добиться максимальных:

  1. модульности
  2. возможности повторного использования кода
  3. простоты и гибкости в использовании.

Идеи

Во-первых, доказавшие свою рациональность идеи из старой платформы:

  1. Приложение делится на модули;
  2. Для вывода кода страниц используется шаблонизатор своей разработки. Причём, он специально сделан максимально простым, дабы избежать анти-паттернов разработки, к которым подталкивает Toolkit, а именно, к перемещению 50 % логики в шаблоны. Примеры того, где так происходит — Bugzilla, Vsem.ru. Используется шаблонизатор, созданный когда-то по мотивам шаблонизатора phpBB2, о чём напоминает синтаксис. Умеет буквально 5 вещей: циклы, IF’ы, INCLUDE (включение другого шаблона), подстановки выражений в код, присваивания; Данные в шаблон передаются просто Perl-хешем;
  3. Конфигурация приложения представляет собой вложенный хеш, хранимый просто в виде Perl-кода;

Во-вторых, идеи, созданные «от противного» по отношению к старой платформе:

  1. Модули теперь создаются по требованию, а не все сразу при старте приложения. Поэтому и modules_allow и modules_deny в конфигурации больше нет;
  2. Обработчик приложения делает фактически только eval {} для отлова исключений и подключение директорий @INC. В старой платформе обработчик делал Много Чего, в результате появлялись жёсткие завязки на некоторые идеи:
    1. Нет виртхостов (хотя они реализуемы) — идея размещения нескольких сайтов в одной базе данных показала свою несостоятельность;
    2. Нет завязки на вызов метода render() у модулей, то есть методы обработки можно создавать любые по желанию;
    3. Нет конфигурации «последовательностей модулей», то есть вызовы разных модулей можно комбинировать в коде как душе угодно;
    4. Нет хеша имён таблиц, сопоставляющего «реальные» таблицы «виртуальным»;
    5. Нет завязки на регулярные выражения в разборе URI, а точнее, нет вообще никакой завязки в разборе URI, как и самого стандартного разбора URI, кроме «страница?параметры»;
    6. Нет завязки на обязательное соединение с БД;
  3. Вся функциональность, имевшая жёсткие завязки, теперь разнесена по модулям, и её можно как использовать, так и не использовать;
  4. Стандартные библиотечные модули больше не предоставляют собой «готовых страниц» — каждый модуль теперь являет собой просто библиотеку функций, а функции, выводившие что-то в шаблон, теперь просто возвращают хеш, который можно подставлять, куда душе угодно;

И в-третьих, новые идеи:

  1. Все обращения к БД из библиотечных модулей теперь оборачиваются в функции и живут в Sway::db::, а рядом с ними лежат SQL дампы нужных им таблиц;
  2. Аналогично обращениям к БД делаются абстракции других операций — иногда хранения (например сессий в кэше), иногда преобразования (например текста сообщений форума);
  3. Версионирование БД;
  4. Поддержка Funq;
  5. EmLog — простой интерфейс, этакий RSS с PUSH’ем для блогов, в качестве транспорта использующий Email.
Источник — «http://yourcmc.ru/wiki/index.php?title=Проблема_модульной_веб-разработки&oldid=4»