-
PHP для идиотов
→ Система привилегий • Окт. 14, 2007, 11:31 д.п.
-
PHP для идиотов
→ Система привилегий • Окт. 13, 2007, 8:27 п.п.
-
Готовые решения
→ PHP Compiler CMF • Окт. 13, 2007, 8:22 п.п.
-
PHP для идиотов
→ Система привилегий • Окт. 13, 2007, 5:29 п.п.
-
PHP для идиотов
→ Система привилегий • Окт. 13, 2007, 1:24 п.п.
Разумеется, приводилось. Во всех проектах стараюсь использовать одно и то же решение - достаточно простое и в то же время достаточно мощное.1. Таблица users - есть поле usergroupid (id группы). Поле обязательное.2. Таблица usergroups - если список полей, начинающихся с префикса "can". Н...
Разумеется, приводилось. Во всех проектах стараюсь использовать одно и то же решение - достаточно простое и в то же время достаточно мощное.
1. Таблица users - есть поле usergroupid (id группы). Поле обязательное.
2. Таблица usergroups - если список полей, начинающихся с префикса "can". Например canview, canwrite, caneditprofile.
3. Таблица userrights - список прав. Редактируется из админки. Добавляем право - в таблице usergroups появляется новое поле.
Дополнительно в таблице usergroups есть еще одна запись - это набор прав для гостей.
Таким образом, любой посетитель, даже гость, получает свой набор прав - запись таблицы usergroups.
Как разрулить ситуацию "модератор такого-то раздела"? Очень просто. Для модераторов создается две отдельных группы. Одна, "номинальная" - это в которой по умолчанию сидят все модераторы сайта. Права у данной группы могут ничем особенно не отличаться от прав обычных пользователей, не-модераторов. И есть вторая группа "модераторов в действии". Эта группа, к которой модератор причисляется временно, только на тот момент, пока он находится в "своем" разделе сайта. У этой группы прописаны все необходимые права, например, право редактировать чужие сообщения.
-
PHP для идиотов
→ CMF Compo • Окт. 13, 2007, 9:59 д.п.
-
Готовые решения
→ PHP Compiler CMF • Окт. 13, 2007, 9:57 д.п.
-
PHP для идиотов
→ CMF Compo • Окт. 12, 2007, 9:38 д.п.
ad3000Так редко когда получается (только при большом везении), особенно если используешь библиотеки от разных разработчиков. Чаще всего получается этакий франкенштейн, где все собрано из кусков, и эти куски глючат на стыках друг с другом. А если ты возьмешь один конкретный фреймворк и будешь пере...
ad3000
Так редко когда получается (только при большом везении), особенно если используешь библиотеки от разных разработчиков. Чаще всего получается этакий франкенштейн, где все собрано из кусков, и эти куски глючат на стыках друг с другом. А если ты возьмешь один конкретный фреймворк и будешь переписывать свою систему на его основе, ты потратишь много времени, чтобы сначала разобраться с ним, потом - чтобы доработать его напильником до нужного тебе состояния, и еще - чтобы дописать нужный тебе функционал. А потом все это еще и тормозить будет… если есть готовая ЦМС, лучше посмотреть на нее орлиным взглядом, найти спорные места, их и усовершенствовать.
-
PHP для идиотов
→ Хранение параметров пользователей • Окт. 11, 2007, 1:49 п.п.
vasa_cЭто шутка была :)На всех сайтах на PHPC, где нужна была регистрация/авторизация, я делал первый вариант. Управлять набором полей профайла можно, но только админу из админки. При добавлении нового поля в профайл добавлялось новое поле в таблицу пользователей + добавлялась запись в таблицу us...
vasa_c
Это шутка была :)
На всех сайтах на PHPC, где нужна была регистрация/авторизация, я делал первый вариант. Управлять набором полей профайла можно, но только админу из админки. При добавлении нового поля в профайл добавлялось новое поле в таблицу пользователей + добавлялась запись в таблицу userfields, где можно было для этого поля указать название, примечание, тип, порядок следования, обязательное или нет, заполняется при регистрации или нет и прочее. Т.е. универсальность есть, но ограниченная.
Для меня все параметры пользователей делятся на 2 группы - те, которыми сам пользователь может управлять, и те, которыми он не может. Первое - это поля профайла. Второе - права. И в том и в другом случае можно сделать "горизонтальное" решение. И если сильно не чудить, получится очень даже красивая, быстрая и надежная реализация…
-
Наш форум
→ Тормоза • Окт. 11, 2007, 1:25 п.п.
-
PHP для идиотов
→ Хранение параметров пользователей • Окт. 11, 2007, 1:23 п.п.
vasa_cЗабудем о базах, таблицах, запросах, эффективности и т.п.Давайте обсудим, какой именно интерфейс хотелось бы иметь с точки зрения программиста-пользователя данной либы, да и вообще админа сайта.Он пытается придумать универсальное решение! На костер его! :)))
vasa_cЗабудем о базах, таблицах, запросах, эффективности и т.п.
Давайте обсудим, какой именно интерфейс хотелось бы иметь с точки зрения программиста-пользователя данной либы, да и вообще админа сайта.
Он пытается придумать универсальное решение! На костер его! :)))
-
PHP для идиотов
→ Хранение параметров пользователей • Окт. 11, 2007, 1:21 п.п.
speedleaderЭтот вариант здесь не годится - новые темы создаются постоянно и без участия разработчиков проекта. Понятно, что в таком случае "горизонтальный" вариант не подходит. Но я говорил о полях наподобие профайла пользователя (как я понял, изначально об этом был разговор)… т.е...
speedleader
Этот вариант здесь не годится - новые темы создаются постоянно и без участия разработчиков проекта. Понятно, что в таком случае "горизонтальный" вариант не подходит. Но я говорил о полях наподобие профайла пользователя (как я понял, изначально об этом был разговор)… т.е. такие поля, количество и типы которых сами посетители изменить не могут.
vasa_c
В принципе, если рассмотреть такую гипотетическую задачу - "очень много полей, очень мало фактических данных", то первый вариант действительно не подходит. Особенно если перейти к предельному случаю, когда количество и типы полей вообще заранее неизвестно, а реальных данных в базе кот наплакал. Если у вас именно такой случай - да, придется воспользоваться вторым вариантом. Но он мне все равно не нравится…
-
PHP для идиотов
→ Хранение параметров пользователей • Окт. 10, 2007, 9:44 п.п.
-
PHP для идиотов
→ Хранение параметров пользователей • Окт. 10, 2007, 9:04 п.п.
Для начала, никто из пользователей никогда не станет заполнять профайл в 1000 полей. Если в системе такое количество параметров, значит у заказчика с головой не все в порядке ;) даже если предположить, что у нас всего 100 полей, все равно, делать для каждого юзверя выборку, которая может вернуть ...
Для начала, никто из пользователей никогда не станет заполнять профайл в 1000 полей. Если в системе такое количество параметров, значит у заказчика с головой не все в порядке ;) даже если предположить, что у нас всего 100 полей, все равно, делать для каждого юзверя выборку, которая может вернуть до 100 записей, только чтобы узнать его профайл - тоже не очень здорово. И где хранить информацию об этих полях, если они хранятся только для непустых значений? Еще одну таблицу городить?
Если волнует проблема свободного места на диске, то не забывайте, что пустые значения в MySQL (NULL, либо 0/пустая строка, если поле NOT NULL) не хранятся физически и не занимают места. Затраты на хранение значения не в виде поля, а в виде отдельной записи приведут к гораздо большей трате места.
-
PHP для идиотов
→ Хранение параметров пользователей • Окт. 10, 2007, 8:03 п.п.
-
PHP для идиотов
→ Хранение параметров пользователей • Окт. 10, 2007, 7:58 п.п.
-
PHP для идиотов
→ Frameworks • Окт. 10, 2007, 5:38 п.п.
-
PHP для идиотов
→ Frameworks • Окт. 10, 2007, 4:08 п.п.
-
PHP для идиотов
→ CMF Compo • Окт. 10, 2007, 1:32 п.п.
ad3000Что ж у тебя за CMS такая, если ты хочешь ее "реорганизовать" и при этом не знаешь, на каком фундаменте она будет стоять после этой реорганизации… :/ неважно, какой фреймворк ты выберешь, хоть Зенд, хоть мой PHPC. В любом случае это будет уже не твоя CMS, а что-то совсем дру...
ad3000
Что ж у тебя за CMS такая, если ты хочешь ее "реорганизовать" и при этом не знаешь, на каком фундаменте она будет стоять после этой реорганизации… :/ неважно, какой фреймворк ты выберешь, хоть Зенд, хоть мой PHPC. В любом случае это будет уже не твоя CMS, а что-то совсем другое и новое.
-
PHP для идиотов
→ CMF Compo • Окт. 10, 2007, 1:29 п.п.
md5Совершенно верно, все фреймворки начинались как небольшие удобные решения, а потом в погоне за универсальностью их авторы превращали их в невесть что. Разработчик должен стремиться сдерживать этот процесс по мере возможности, не допускать беспричинного раздувания движка. Писать отдельные модул...
md5
Совершенно верно, все фреймворки начинались как небольшие удобные решения, а потом в погоне за универсальностью их авторы превращали их в невесть что. Разработчик должен стремиться сдерживать этот процесс по мере возможности, не допускать беспричинного раздувания движка. Писать отдельные модули - на здоровье. А чем "универсальнее" ядро, тем сложнее разбираться с ним (тем оно глючнее, тормознее, несовместимее ни с чем и т. д.) Мой PHPC растет в том плане, что у него появляются все новые и новые полезные возможности - небольшие и обязательно вызванные реальной необходимостью в них. Архитектура же при этом не меняется, она была избрана один раз и навсегда. Если я захочу попробовать другое архитектурное решение, я напишу новый фреймворк.
