vitus: comment 22

vitus
Tue, 22 Jan 2013 12:34:29 +0400

Даже на самом небольшом wiki, если есть возможность редактирования без премодерации -- возможность откатить изменения необходима.

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

Мы не делаем wiki, мы делаем именно CMS.

Я с крайним подохрением отношусь к идее "вики по какому-нибудь программному продукту". Сколько я за последнее время видет продуктов, у которых документация была в формате wiki, это значило что у них нет документации. Форум и то лучше. Кстати, вот форум - это нормальный usecase для stilllife, в отличе от wiki.

Добавлю только что я хотел бы, чтобы "не менять другие объекты FS если в них содержатся первичные объекты" было MUST а не SHOULD.

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

Ну никого же не напрягает что кто-то выполняет update в базе данных sqlite, хотя это файл, в котором содержится дохрена первичных объектов. Не делайте идола из И FS. FS и DOM это такие деревья. И то и другое равно устойчиво к изменениям одного маленького фрагмента.

Операция вставки внутрь XML-файла блока, который также является валидным XML, если вставка происходит между тэгами (а не посередине тэга) не может породить невалидный XML, или я ошибаюсь?

Операция вставки валлидного XML-блока - это абсолютно бессмысленная вещь для задачи "приделать общее оформление ко всем страницам сайта".

Как правило, это общее оформление требует, чтобы содержательный текст вставлялся как содержимое какого-то XML-элемента оформления, а не наоборот. А посколку URL, а значит и путь в ФС у нас адресует содержательный объект, SSI не решает задачи пределать к нему оформления, если мы не допускаем открытия тэгов в одном инклюде (верхнем), а зарытия в другом (нижнем).

Ну и записать сайт на сидюк становится невозможныМ.

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

С какой стати нам может потребоваться обновление всех html при апдейте? Сайт организован как дерево. И обновления пропагейтятся по этому дереву в основном снизу вверх, от листьев к корню.

То есть если не включать статистических счетчиков в общее оформление (а это следует явно запретить) то обновляться будет 3-4 файла,. Ну пусть десяток, если пользователь напихал в пост кучу тэгов.

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

Так вот -- блок 'related posts', например, помогает машинам,

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