Несколько вопросов возникших при написании CMS

332
.
А что за цмс? для соц сети или чего то другого? Что в ней будет?
.
~XeOn~ (04.12.2012 / 02:43)
1) Взять за основу фрэймворк (смотрю в сторону Yii) либо поковырять готовые цмс, и взять оттуда реализации структуры, точнее плюсы из нескольких цмс, и обойтись без ФВ?
Тут уже как тебе удобно, если уверен в своих силах то можешь взять и свое что нибудь наваять, если лень или еще что то то конечно фреймворк, ну и плюсов с использованием фреймворка больше (проверенная годами архитектура, набор библиотек из коробки и прочее), лично я когда начинал, начинал с нуля т.к. никаких ограничений по началу не накладывалось писал как вздумалось, важнее всего было для меня именно это.
2) Модульность, структура файлов понятна, но как быть с БД, а точнее с пользовательскими настройками для каждого модуля? Хранить все в одной таблице (как в ждоне) не вариант, это неправильно + теряется модульность. Как быть?

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

3) И пока самое сложное для меня (незнаю почему, но решить немогу) это организация загрузки настроек пользователя и гостя, определение настроек для гостя и пользователя отдельно, естественно для каждого модуля отдельно.

А что там сложного? Определяешь настройки по умолчанию для пользователей и гостей и сохраняешь их куда нужно, для пользователей сделать возможность их редактирования и пихать их например в туже таблицу из ответа на пункт 2.
.
~XeOn~ (04.12.2012 / 16:04)
Впринципе идея неплоха
К примеру есть таблица user_module_settings, и есть 20 модулей, получается в таблице 21 поле, 1 - ид юзера, остальные - остальные - поля с настройками для каждого модуля,
id f
Ну это единственный нормальный вариант ! Ну не пихать же все в одно поле !
.
(\/)____o_O____(\/)
~XeOn~ (04.12.2012 / 15:56)
Для каждого юзера создавать ини файл с настройками? О_о
для общих настроек, пользовательских не так и много, можно впринципе даже отдельную таблицу не создавать
.
Кстати не счет шаблонизатора могу посоветовать quicky ! Это оптимизированный смарти если интересно то погугли!
.
Fenix_61 (04.12.2012 / 19:47)
Кстати не счет шаблонизатора могу посоветовать quicky ! Это оптимизированный смарти если интересно то погугли!
Читал я о нем, последняя версия кажись 2009 года. Все-же решил нативный юзать.
.
~XeOn~ (05.12.2012 / 01:58)
Читал я о нем, последняя версия кажись 2009 года. Все-же решил нативный юзать.
Ну тогда проще будет свой написать тем более столько статей об этом!
.
~XeOn~ (04.12.2012 / 02:43)
В общем начал писать свою цмску (не спрашивайте зачем, джон не катит) и вот при организации структуры цмс понял что хорошую структуру не смогу пока реализовать, и собственно появился такие вопросы:
1
1. раз уж решил писать цмс с нуля, значит должен был иметь ответ на этот вопрос до этого решения;
2. Что понимается под пользовательскими настройками? Я реализовывал у себя все задачи в контексте отдельных модулей, то есть под пользовательскими настройками я понимаю некий модуль, который хранит в базе пары Ключ=Значение. Другие модули могут писать свои ключи и значения через этот модуль и получать их из него, тем самым реализовывая настройки для пользователей (связал ключевые пары с пользователем);
3. У меня реализовано по средствам null-объекта, есть пользователь (объект класса User), есть гость (объект класса DefaultUser extends User) для которого не задается пароль но есть идентификатор. Так, ты работаешь с гостями как и с обычными пользователями с той лишь разницей, что под гостем может зайти любой пользователь (так как нет пароля) + дополнительная логика для выбора гостя по умолчанию
Всего: 18