Quote from: AKots at Mar 05, 2008, 08:33 AM
Непонятно, зачем менять структуру для интеграции, и без этого можно отлично обойтись. Правда не совсем ясно, что имеется в виду под пользовательскими таблицами.
Описываю то, как я вижу процесс интеграции. Вполне возможно мое поверхностное знание сервиса не позволяет мне придумать более легкой задачи.
Цель: интегрирование MODx и IPB v2.3.4
Под интеграции понимается: единый реестр пользователей.
Возможность авторизации/регистрации как с сайта, так и с форума.
Вывод на страницы сайта данных форума: 10ть последних тем форума, 10ть популярных тем, самые активные пользователи итд. Согласна, что последний пункт мало относится к интеграции и не имеет сложностей при реализации. Добавила исключительно, чтобы описать полностью задачу, которую себе поставила.
Реализация: первоначальная идея заключается в размещении таблиц MODx и IPB в одной базе данных, что автоматически избавляет от необходимости решать вопросы с подключением к двум разным БД как на сайте, так и на форуме. Недостатком этого является принудительное использование cp1251_general_ci, тк IPB не дружит с UTF8 (последнее предложение лишь замечание, вопросом UTF8 в IPB пока не занималась, хотя уверена, что, скорее всего, существуют готовые решения проблемы!).
Далее: общая регистрация пользователей: как я себе представляю это возможно реализовывать двумя способами. А именно: созданием единой таблицы для хранения инф о пользователях, которая будет содержать в себе информационные поля как сайта, так и форума. Развивать именно эту идею не буду, так как она мне не нравится. Вместо этого я считаю будет приемлемым использовать 2 родные таблицы изменяя при этом принципы регистрации на сайте и форуме. Под изменениями подразумевается добавление отсутствующих полей. При заполнении пользователем анкеты, данные будут записываться сразу в две таблицы (те дублироваться).
Единая авторизация: заключается в изменении записи в Cookies. Где бы не производилась регистрация, производится запись авторизации сразу в двух системах.
Если есть более легкие способы, уточнения или предложения буду рада выслушать их)
Quote from: AKots at Mar 05, 2008, 08:33 AM
А менять структуру хранения данных – вообще нонсенс. Вся система завязана на имеющуюся структуру, и при ее изменении потребуется переписать не только ядро, но и многие популярные сниппеты, напрямую обращающиеся к базе.
Под изменением системы хранения контентных данных я имела в виду разделения информации на дополнительные поля в таблице. А именно меня на данный момент мало устраивает хранения всего контента как единой записи, не считая вынесения заголовков в отдельное поле. Хотелось бы представить структуру хранения в виде нескольких полей внутри одной таблицы, которая будет отдельно содержать теги рисунков, что в свою очередь позволит довольно быстро изменять пути в случае изменения места хранения, запускать скрипты для очистки недоступных рисунков с внешних источников. Задача реализуется изменением лишь файлов отвечающий за запись и чтение информации, добавив в обоих случаях функции парсинга. Естественно при этом несколько упадет скорость чтения и записи.
При этом я не вижу проблем с взаимодействием всей системы при таком изменении. Возможно, это из-за того, что я пока плохо представляю внутренне устройство CMS.
Quote from: AKots at Mar 05, 2008, 08:33 AM
То есть фактически ставится цель разработки новой CMS на основе MODx – не могу себе представить проект, для которого это действительно нужно.
Такой цели не ставится. Нет ни времени, ни желания. Если бы была такая цель, то я начала бы написание с нуля, при этом активно "разглядывая" уже существующие сервисы.
Quote from: AKots at Mar 05, 2008, 08:33 AM
И вообще-то не все ли равно, как построена база данных? Для успешной работы с MODx в подавляющем большинстве случаев не требуется непосредственное обращение к базе.
Нет, не все равно, тк лично меня беспокоит вопрос переноса данных с одной системы на другую. Естественно такой потребности может никогда не возникнуть, но в теории он реален. Писать скрипт экспорта при смешанном хранении данных мне кажется несколько не удобным. В тех статьях, которые я читала и на основании которых я создавала свои критерии выбора CMS, очень советуется обращать на архитектуру хранения данных в сервисе особое внимание.
☆ A M B ☆
.