Что то мне никак не удается начать писать мултиадминку. Далее идет текст предназначенный для меня лично - мне проще рассуждать вслух, чем думать в голову. Зафиксирую в тексте некоторые мысли и идеи - скорее всего из за отсутствия однозначного понимания дело не движется. Во первых мултиадминка делается на платформе блоголёт. Это означает, что мултиадминка будет использовать уже существующие классы блоголёта.

Меню в мултиадминки будет не таким как админке - в админке просто параграф со ссылками, в мульти админке это будут меню в обычном понимании, например как сейчас в блоголёте по умолчанию меню "Контакты". Таким же образом будет организовано меню. Для мултиадминки нужен другой инсталлятор, так как мултиадминка не является блогом. Поскольку мултиадминка не блог, то не нужны виджеты для блога, не нужен RSS, да и вообще посты тоже не нужны. Нужна другая главная страница, так как в ней не используются посты. Сразу отваливаются следующие классы за ненадобностью: TArchives, THomepage, TMetawidget, TRSS, TPosts и та далее по списку классов. Потребуется наследник от класса TCommonTags, так как сайты можно будет разбивать по категориям. Можно применить аналогию, где сайт в мултиадминке - это пост в блоге. Для мултиадминки не нужна публичность - пользователь у нее один, который входит по логину с паролем. С одной стороны все упрощается - не нужно всего того, что есть в блоге. С другой стороны необходимо построить меню, где каждая страница обрабатывает форму. Вообще же хорошо, что провел здесь аналогию между постами и сайтами: изначально планировалось, что сайты - это элементы массива в TSites, но теперь возможно сделать для сайта свой объект. Тогда упрощается (или усложняется) работа с категориями сайтов - код надо будет перлюстрировать для применения его к мултиадминке. Тогда будет еще более универсальный класс по управлению категориями, метками и сайтами.

Сейчас по подписанному событию создается экземпляр класса TPosts в обработчиках событий. Скорее всего придется абстрагировать имя класса для постов - для блогов это будет TPosts, а для сайтов TSite. Это вероятный источник нестабильности, так как имя класса источника событий не будет фиксированным., но вряд ли, так как уже сейчас например нефиксировано имя свойства для которого хранится инфа. То есть TCommonTags в TPost обслуживает два свойства - categories и tags.

Случайно получившаяся аналогия постов и сайтов кажется преподносит приятные сюрпризы: вероятно даже не придется переделывать класс THomepage (но это надо еще посмотреть), ведь за отображение TPost отвечает его метод GetTemplateContent, который мог бы быть переделан для вывода инфы о сайте. Идеология блоголёта построена на идеях ООП, и естественным образом за отображение поста отвечает сам пост, то есть его класс TPost, а остальным классам дела нет до того, каким образом класс генерирует html. Сайты могут тоже генерить свой html. Но не знаю насколько это будет актуально: я планировал вывод списка сайтов не виде похожем на список постов, а в виде таблицы с чекбоксами.

Кажется фиксация идей осуществилась - не судите строго за мой поток сознания, я же писал для самого себя, а не для вас, дорогой читатель.

RSS комментарии к этой записи Рубрики: Мультиадминка, Разработчику