КС2

Вроде как бы я почти наверное доделал свою систему... может быть. Чтобы начать ваять, собственно, сайт, нужно сначала решить, что и как он будет делать.

Два основных направления - это статьи и форум.

Форум, наверное, будет почти таким же. По крайней мере мне от него больше ничего не надо. Со статьями придется поломать голову, поскольку теперешняя система явно мешает работать.

Как будут работать категории? Нужна ли какая-то иерархия?
Как будут посылаться статьи?
Каков максимальнй размер статьи? (В 64 килобайта уже однажды уперлись, значит надо больше.)
Как все это должно выглядеть?
Какая будет навигация?
Как будет организовано соавторство? (То что оно должно быть - очевидно.)
Как будет храниться инфа по играм? (Третье направление получается: сделать игробазу.)
Как будут огранизованы сериалы?
Скриншоты?
Жанры статей? (Я планирую сделать так, чтобы к статье можно было приписать сколько угодно жанров, а не 1 как сейчас.)
Комментарии?

Надо придумать структуру таблиц. Приблизительная структура таблиц:

Таблица единиц контента (статей):
ID статьи, ID автора(ов), Заглавие, Текст, ID категории, ID жанров, ID картинки(ок)

Таблица авторов:
ID автора, Разная информация об авторе, ID статей где стоит его авторский айди

Таблица категорий:
ID категории, Наименование категории, ID статей относящихся к данной категории

Таблица жанров то же самое.

Таблица картинок:
ID картинки, ID статьи(ей) в которой она используется, Тип картинки, Адрес места размещения картинки-превью, Адрес места размещения полной картинки (если тип картинки: скриншот)

При обращении статье, к карточке определенного автора, к списку статей в определенном разделе и т.п. скрипт будет смотреть в соответствующих таблицах необходимую информацию. Все изменения будут происходить под контролем скрипта, который будет активировать последовательность действий по корректировке инфы в таблицах.

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

Я бы сделал примерно так. И таким образом ответы будут следующие:

> Как будут работать категории? Нужна ли какая-то иерархия?
В зависимости от направленности сайта. В нашем случае категории будут

> Каков максимальнй размер статьи? (В 64 килобайта уже однажды уперлись, значит надо больше.)
Ограничение должно быть до, например, 500 кб для текстовой информации. Особо большие статьи будут автоматически делиться на более мелкие и сохраняться под отдельными айди типа ID-№ (соответственно, нужна еще одна ячейка соответствующей таблице). И надо написать, что "если вы хотите опубликовать материал более N кб, то обратитесь к администратору".

> Как все это должно выглядеть?
Это тема для отдельного разговора.

> Какая будет навигация?
Рубрикаторы, которые будут выводить список статей в зависимости от даты, от автора, от категории, от жанра игры (если это обзор игры) и по прочим параметрам. Обязательно возможность сортировать выдающиеся списки по дате публикации, по названию по алфавиту и т.п.

> Как будет организовано соавторство? (То что оно должно быть - очевидно.)
Несколько ID авторов в соответствующей ячейке.

Ну и всё в том же духе. (Сейчас некогда писать - с работы убегаю домой.)

Идея понятна, но у меня разных таблиц не будет. Это одна из фишек фреймворка. Есть всего десять стандартных таблиц, три из которых отвечают за ноды, атрибуты и линки.

nodes:
id, type, alias, parent

attrs:
nodeId, name, type, value, textValue

links:
nodeIdA, type, nodeIdB

При добавлении, скажем, статьи будет добавляться один нод (id=1012,type=document,alias=205,parent=9). Parent отвечает за категорию. Не очень элегантно, но делать хитрые алгоритмы для всяких иерархических штучек нет пока времени. Далее, к ноду будуь созданы атрибуты - для текста, для автора, для заголовка, для даты и т.д. А для ассоциации с жанрами будут использоваться линки.

Единственная проблема - система не может сортировать ноды по атрибутам, у которых значение хранится в textValue (для поиска а-ля гугль). Так что по названию статьи сортировать пока не получится. Хотя если надо будет, то я что-нибудь придумаю.

Вообще, ты меня немного не так понял (или я не так выразился). Кодинг на уровне таблиц, нодов, ячеек и проч. я вытяну. Другое дело - интерфейс и логика работы. Скажем, я давно хотел сделать так, чтобы, отредактировав статью, я мог ее послать обратно на "одобрение" автору. Это значит, что нужна возможность сохранять изменения в статье, не публикуя ее. Тоже, кстати, фишка удобная. Чем забивать харддрайв промежуточными версиями, я бы охотнее сохранял их на сайте, тем более что другие редакторы тогда смогут "доделать" статью. Еще Аквен когда-то просил, чтобы можно было пометить "на редактировании у такого-то".

Вот такие вещи неплохо бы продумать заранее.

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

Сюда определенно, но я не знаю, как это реализовать технически. Давайте просто сохранять изначальную версию статьи, и давать гже-то на нее ссылку?

Ок, так конечно можно, но вручную искать изменения долговато. Может ссылка будет даваться на статью, где измененные моменты отмечены красным шрифтом?

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