From: Maxx <de...@on...> - 2002-05-24 18:04:00
|
Все ответы - мои личные и выражают лишь мою точку зрения. Независимо от того, что в ответах употребляются императивы, данная информация не обязывает её использовать и несёт лишь консультативный характер. Это чтобы все всё правильно поняли. Теперь к делу: 1. Для чего предназначена система? Для построения веб-сайта (в идеале - любой направленности) и его управления. В подавляющем большинстве случаев администрирования не должно требоваться никакого другого стороннего ПО, т.е. система должна быть самодостаточной (хотя, здесь можно спорить). 2. Как она строится? Относительно независимые самоустанавливающиеся и самонастраивающиеся модули. Два "-щиеся" означает, что для установки модуля достаточно лишь скопировать его в каталог системы, после чего появятся соответствующие элементы меню в админском интерфейсе, где они могут быть активированы и включены в сайт. Модули должны быть максимально независимы (наверное более верным будет термин "плагин"), однако, так или иначе, потребуется использование общих библиотек, но этот вопрос легко решаем. 3. Какие функции осуществляются ядром? Авторизация, общий интерфейс, подключение плагинов и их вывод на пользователя (т.е. обработка клиентской части). Вроде это всё, и не более того. 4. Какие модули являются необходимыми для функционирования системы и, следовательно модут быть частично или полностью интегрированы в ядро? Никакие. Ядро - это ядро, модули - это модули. 5. Где данные-то хранить? и самое главное как с ними прозрачно работать? Для каждого модуля должен существовать набор обязательных функций (методов?). Нечто типа Сохранить_в_БД(), Сохранить_на_диске(). В этих функциях/методах нужно использовать абстрактную модель "хранилища". В случае с БД наверное стоит употреблять лишь те запросы, которые являются стандартом для большинства СУБД. ---------------------------------------------------------- Продолжу список: 6. Пользователи. Есть Админы, есть Юзеры. Наверное будет лучше всего реализовать систему ACL'ов и пользовательских групп для максимальной гибкости. Каждый пользователь может быть членом любого кол-ва групп, для которых определяются различные уровни доступа (смотреть : создавать) к различным модулям. Так же уровни доступа могут назначаться в личном порядке для каждого пользователя. 7. Для реализации клиентской части обязательно использование шаблонов. Я не знаю как работается с XML+XSLT, но наверное лучше использовать эту технологию. Стандарт как никак. 8. Мультиязыковость - обязательна. Предлагается использовать gettext. Удобно, просто, быстро. На текущий момент это всё. Как что придумаю - всяко напишу в сюду ;) |
From: Antoxa <an...@ph...> - 2002-05-24 18:42:13
|
Hello Maxx, Saturday, May 25, 2002, 1:04:01 AM, you wrote: M> 5. Где данные-то хранить? и самое главное как с ними прозрачно работать? M> Для каждого модуля должен существовать набор обязательных функций M> (методов?). Нечто типа Сохранить_в_БД(), Сохранить_на_диске(). В этих M> функциях/методах нужно использовать абстрактную модель "хранилища". тут вот нифига не понял, что ты имеешь в виду, что для каждого модуля должны быть некие методы, что-то там сохранить... может быть это просто пиво :) M> ---------------------------------------------------------- M> Продолжу список: M> 6. Пользователи. M> Есть Админы, есть Юзеры. Наверное будет лучше всего реализовать систему M> ACL'ов и пользовательских групп для максимальной гибкости. Каждый M> пользователь может быть членом любого кол-ва групп, для которых определяются M> различные уровни доступа (смотреть : создавать) к различным модулям. Так же M> уровни доступа могут назначаться в личном порядке для каждого пользователя. предложение такое: каждый модуль определяет набор действий, которые он обрабатывает, например для форума это будут 'добавить топик', 'ответить' и т.д. дополнительными параметрами должны быть: - группа для которой определено данное действие - подраздел для данного действия (например раздел форума) - lparam, sparam (win32api :) ) - long param и string param - дополниьельные парамеры, по которым модуль может самостоятельно переопределить уровень доступа к ресурсу на время данного запроса и для ядро поддерживает структуры для определения возможности доступа к ресурсам модуля относительно групп и конкретных пользователей (хотя последний пункт - очень спорный) это вс применимо тогда и только тогда, когда только ядро управляет доступом, т.е. модули сами не могут определять кого им пускать а кого - нет... M> 7. Для реализации клиентской части обязательно использование шаблонов. Я не M> знаю как работается с XML+XSLT, но наверное лучше использовать эту M> технологию. Стандарт как никак. кстати, обязательно должна быть возможность генерить статику, хотя, это не вывод клиенту, а модуль скорее. типа print-version M> 8. Мультиязыковость - обязательна. Предлагается использовать gettext. M> Удобно, просто, быстро. где почитать про gettext ? -- Origin: - Всегда помни, - улыбался Бог, - Я всегда посылаю вам только ангелов, и никого кроме них... -- Антон Поваров [ ICQ: 85431470 ] |
From: Andrey A. <mv...@ph...> - 2002-05-25 01:59:54
|
Subj |
From: Andrey A. <mv...@ph...> - 2002-05-25 02:01:05
|
3fLuLCD/IOX55SDiIOTu6uHz6u7i8ero6SDq7u3i5fDy7fPrLCDu7e4g7eDk7iDoIOXx6+gg 7eDk7iDy7iDq8+T7DQrx7uLg8vwgPw0KDQotLSANCtEg8+Lg5uXt6OXsLA0KIEFuZHJleSAg ICAgICAgICAgICAgICAgICAgICAgICAgbWFpbHRvOm12Y19hYWFAcGhwY2x1Yi5uZXQNCg0K |