Некоторые планы по ЛибАреа (LibArea)

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

Например, не так давно предложили сделать еще один шаблон, которые полностью отличается от этого. Отлично! Это хорошая идея и она будет реализована. Но на данный момент, это не главное. ИМХО.

Смотрим. У нас есть статьи и глобальная система навигации по сайту (фасеты), которые мы можем применять везде и делать с помощью них различные интересные штуки (категории, теги и т.д.). Эти фасеты уже работают на статьях, есть добавление, подписка на них. От того подписаны мы или нет, мы видим посты в ленте (после авторизации).

Отлично!

Но в движке есть одна часть, которая нуждается в немедленной переработке. Я говорю про саму структуру и три таблицы:

links — (сайты)
facets_links_relation (связь с фасетами)
votes_link (лайки)

По названию таблиц и по php файлам далее (контроллеры, модели, шаблоны) можно четко сказать, это ссылки (сайты). Однако, есть необходимость добавить программы.

Например. Есть сайт: «InstantCMS», которые представляет собой сообщество по поддержки программы InstantCMS размещенный на GitHub. Отличная CMS! Есть сайт «PHP Микрофреймворк HLEB» и программа, на которой сделан Agouti.

Как мне добавить программы?

Мы можем добавить поля в таблицу links, но по названию таблицы, полей и файлов далее будет путаница.

Везде мы будем видеть LINKS (ссылки), а там будут и программы?

А если мы захотим, или нам понадобиться добавить ещё что-то: товары, работу… не важно, ситуация будет еще плачевней.

Нам необходимо назвать эти 2 таблицы, поля, файлы (я упрощаю) по другому. Мы просто в таблицу добавим поле type, где запись будет говорить, что перед нами: links, soft и т.д.

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

Все по разному называют такие таблицы и поля:

• Osclass — _item
• eSyndiCat — listing
• Flynax — listing

Бывает — предметы (items), предлагают resources, посмотрим. Это детали, рабочие моменты. Как бы мы не назвали должно быть более «лучше», чем жесткое название links.

Меня успокаивает только то, что 2 перечисленные выше таблицы (думаю) не особо пользуются спросом. Их легко можно удалить, а далее за место них добавить новые. Если кто-то не захочет их удалять, то просто напишите мне в Discord, подготовлю инструкции по изменению имен таблиц и полей. Но в этом случае работы будет больше (через phpmyadmin или запросами делать).

В общем, мы ставим очередную точку, делаем релиз на GitHub и фиксируем то, что есть.

Следующее обновление будет заключаться в добавлении 2 новых таблиц и удалением эти (Links).

Обычно все задачи по созданию чего-то крутились вокруг 3 вещей:

• универсальная система публикацийl;
• создание структуру;
• возможность коллективной работы.

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

Создание команд и возможность коллективной работы

Вот пример. Пользователь может создать блог. А может он пригласить соавторов, чтобы совместно вести блог? Мы можем сейчас совместно редактировать какую-то статью и т.д.? Не думаю.

Это предстоит сделать.

Но сперва, мне нужна более гибкая структуру в базе.

Это планы… )