Change Log

Где хранить системную конфигурацию | 2016-06-14
Проблема: скины требуют самоконфигурации

• для thisSite - заголовки, настройки макета
• для editMode:
  • синтаксис, собираемый, в частности, из Cookbook/*-Syntax
  • альтернативная форма Site/EditForm (но вообще-то она скорее нужна даже для phFieldProcessing.php)

Оказывается, существует способ создавать дефолтные Wiki-страницы внутри папок самих скинов (в /wikilib.d ), чтобы скины можно было распространять "как вещь в себе" (см. SkinGuidelines#bundling)

Но мы пока так не будем делать, поскольку у нас на данный момент задача распространять как "вещь в себе" не скины и рецепты по отдельности (что существенно сложнее), а целиком всю установку PmWiki

Я попробовал вынести Site/EditForm в editMode/wikilib.d/ , но это вызвало следующие проблемы:

• скин editMode используется только во время редактирования, но посмотреть-то код тоже нужно бывает нужно
• значит, тут же надо искать файлы и в случае скина thisSite
• чтобы не лепить костылей (в виде перечисления руками всех мест, где искать), необходимо будет переместить editMode внутрь thisSite, (см. SkinTemplates)
  • однако Site/EditForm , вообще-то, нужна скорее для phFieldProcessing.php, а не для макета, так что такие трудозатратные действия выглядят излишними

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

Окончательное решение: в результате макеты дизайна все-таки были объединены, концепция хранения "мастер-страниц" внедрена, наряду с концепцией ThisSite

Чтобы доделать Карту Сайта так, как я задумал, надо вытащить из Uploadify функционал, связанный со вставкой кода в тело страницы в режиме редактирования, и оформить его в виде отдельного решения. Это факт.

Но, глянув на этот Uploadify я "че-т приуныл"... Это будет тяжко.

Проблема в чем? Проблема в том, что очень много сущностей. Less, php, js, настройки wiki. Скрипт сложный и точно будет требовать допила в будущем. Теперь предположим, мы внедрим это на master02. На master03 И pmwiki.ru И master04 будут копии. Правка косяков на master02 приведет к необходимости обновлять все остальное.

Кроме того, скрипт требует допила:

• выпила "вставки кода в тело страницы" в отдельный никак не связанный, но конфигурируемый рецепт
• отделения конфигурации от ядра, для обеспечения обновлений
• возможно, внедрения css кода внутрь рецепта, чтобы сократить количество сущностей

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

• выпиливаем uploadify из master02
• переносим его на отдельный uploadify.demo.finar.ru
  • разделяем конфигурацию, wiki-конфигурацию, ядро
  • внедряем версионность всего так, чтобы править/допиливать можно было в одном месте, копируя это только туда, куда нужно в данный момент
• внедряем по-новой на master03, затем pmwiki.ru, затем master04... как-то все сложно и геморно.

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

В связи с этим есть гипотеза, что начиная с версия master03 должна превратиться просто в master, а pmwiki.ru должна стать ее подфермой.

Итак, план действий:

• выделяем отдельный Рецепт для Editmode, связанный со вставкой кода в тело страницы в режиме редактирования, применяем его ко всему Синтаксису
• завершаем прочие работы по master02
• делаем репликант на --master03-- master
  • после этого выпиливаем uploadify из master02
  • рефакторим рецепт uploadify
  • из master.pmwiki.ru делаем ферму
    • суть в том, что pmwiki.ru сам по себе остается мастер-движком, где хранятся все "мастеры" всех рецептов
    • содержимое сайта pmwiki.ru с уникальными статьями и надстройками станет его поддиректорией (по аналогии с мемофильмом), содержащей по сути только визуальную спецификацию + дополнительный контент
    • чтобы создать новый сайт, достаточно скопировать весь master.pmwiki.ru кроме его поддиректории pmwiki.ru
  • отныне все мастеры внедряемых решений живут на pmwiki.ru, далее мы просто добавляем "комментарии" и "sourcecode", версионность мастеров более не используется.

Окончательное решение:

• master02 должен быть последним последовательным мастером, без "тяжелого" функционала, содержащая только ядро
• версия master03 становится базовой master, в которую очень аккуратно и размеренно внедряются все возможные Рецепты с версионностью, документацией и т.д.
• pmwiki.ru должна стать "подфермой" master.pmwiki.ru (если это получится сделать), чтобы сократить количество копий.