-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Светлана PHP
Guest
1) Со стороны ядра должна идти проверка пользователя: кто или что является пользователем.
2) Есть мнение отказаться от SQL DB и бацать всё в XML! Ура! Слава XML! - это к вопросу о прописывании конфигураций страниц в xml файлах их содержащих.
XML/XLST, возможно, имеет смысл пихать для решения задач представления данных для различных MEDIA: браузер, мобила, пда, принтэр.
Если же Вы, к примеру, решите устроить поиск с помощью этой связки... Не думаю что Ваши пользователи остануться довольными - хотя идея супер! летает в воздухе! Лови а то поймаешь!
2) Есть мнение отказаться от SQL DB и бацать всё в XML! Ура! Слава XML! - это к вопросу о прописывании конфигураций страниц в xml файлах их содержащих.
XML/XLST, возможно, имеет смысл пихать для решения задач представления данных для различных MEDIA: браузер, мобила, пда, принтэр.
Если же Вы, к примеру, решите устроить поиск с помощью этой связки... Не думаю что Ваши пользователи остануться довольными - хотя идея супер! летает в воздухе! Лови а то поймаешь!
chaan
Guest
Нечто, под
понимаются функции по работе с модулями/функциями(запуск, удаление и т.п.)?
-- Мне кажется, что это реализуется через модули или, если смотреть на мою схему, в процессорной обработке(получение страницы). Просто под ядром в данном случае я подразумеваю то, что не связанно с выводом информации и её обработкой напрямую, только через модули.
Светлана PHP
Guest
Часто стоит задача среди внешних пользователей отобрать тех кто:
- залогинин был хотя бы раз
и/или
- два раза
и/или
- когда-либо вообще
и/или
- имеющих определённый IP
и/или
- чего-то там ещё
И только ЭТИМ пользователям должно быть допустимо показывать ОПРЕДЕЛЁННЫЕ страницы web-сайта
И после этого ядро не должно понимать кто вообще тут пришёл, блин?
- залогинин был хотя бы раз
и/или
- два раза
и/или
- когда-либо вообще
и/или
- имеющих определённый IP
и/или
- чего-то там ещё
И только ЭТИМ пользователям должно быть допустимо показывать ОПРЕДЕЛЁННЫЕ страницы web-сайта
И после этого ядро не должно понимать кто вообще тут пришёл, блин?
chaan
Guest
Ядро -- среда для работы. Ядро не соприкасается с отображением. А то, что Вы описываете, реализуется с помощью, например, модуля авторизации. Он может прятать страницы, и будут выдаваться 404 или 403. Если же Вы имели ввиду, что, если вошел админ, например с определенного ip, система сама его определит и наделит бо`льшими правами, то это также реализуется с помощью модуля. Мне кажется, что так логичнее. Можно хоть другой сайт выдавать, если в системе сайт не один.
Светлана PHP
Guest
С Ваших слов следует, что при каждом запросе должен активироваться или подключаться (бог его знает, мож Вы плагины используете или пишите процедурами) этот модуль авторизации?
Так если оно так, не логичнее ли всё же будет перенести функционал "авторизации" в ядро?
Вспомним хотя бы *NIX архитектуру да что там WindowsNT: всё начинается с того, что система определяет кто есть кто. И после этого каждое действие пользователя проверяется на правовую возможность исполнения.
Так если оно так, не логичнее ли всё же будет перенести функционал "авторизации" в ядро?
Вспомним хотя бы *NIX архитектуру да что там WindowsNT: всё начинается с того, что система определяет кто есть кто. И после этого каждое действие пользователя проверяется на правовую возможность исполнения.
Светлана PHP
Guest
То тогда мы начинаем использовать DOS PC и забываем о многопользовательских мультизадачных системах.
Вы не ответили на мои вопросы. Сравнение с ОС проводить все-таки некорректно. Ну и QNX пока справляется.Светлана PHP
Guest
Можно использовать FrontPAGE
То есть всё таки надо?
Тогда меняем класс представляющий API. При этом некоторый абстрактный класс не меняем или дополняем.
-~{}~ 17.04.05 18:06:
Слушайте, если перед Вашей CMS встанет задача обеспечение документооборота на предприятии? Вы будете писать Workflow edition?
Светлана PHP
Guest
Круто!
Нечто!
Я вот тут идею толкаю, что CMS, как клиент-серверному ПО, всегда нужно знать кто с ней работает: и если даже уровень дискретности твоего модуля авторизации составляет любит/не любит, по отношению к другому модулю, ТО даже в этом случае ты замахаешься плугинить или инклюдить свой модуль авторизации. Посему его логично размещать в ядре (в смысле функциональность)
Ты мне говоришь: "А что если заказчик скажет, пошёл ты со своей CMS! Сделай мне сайт за 500 баксов из трёх страниц"
То что тогда?
Тогда бы я послала заказчика к тебе.
У меня есть пара клиентов: которые ставят картинки в скрытые разделы (домашнее фото - не порно) и на них заходят родственники, которые живут далеко. Один клиент залогинивает скрытые странички, другой наложил ограничение, что только с израиля просмотр допустим. Есть юр контора, которая выставляет свои заключения... и тоже пускает только через логин и пароль.
Нечто!
Я вот тут идею толкаю, что CMS, как клиент-серверному ПО, всегда нужно знать кто с ней работает: и если даже уровень дискретности твоего модуля авторизации составляет любит/не любит, по отношению к другому модулю, ТО даже в этом случае ты замахаешься плугинить или инклюдить свой модуль авторизации. Посему его логично размещать в ядре (в смысле функциональность)
Ты мне говоришь: "А что если заказчик скажет, пошёл ты со своей CMS! Сделай мне сайт за 500 баксов из трёх страниц"
То что тогда?
Тогда бы я послала заказчика к тебе.
У меня есть пара клиентов: которые ставят картинки в скрытые разделы (домашнее фото - не порно) и на них заходят родственники, которые живут далеко. Один клиент залогинивает скрытые странички, другой наложил ограничение, что только с израиля просмотр допустим. Есть юр контора, которая выставляет свои заключения... и тоже пускает только через логин и пароль.
Нечто
Психолог РНРClub
Светлана PHP
omg, я же не говорю, что авторизация не нужна!
Я рассматриваю ядро как связующее звено между потребностями - запрсом и их удовлетворением - функционалом. Само ядро ничего делать не умеет, кроме как правильно адресовывать запросы, исходя их имеющихся в распоряжении расширений. Если библиотека авторизации присутствует, то она будет подключена и, соответственно, ее функции будут срабатывать на определенные события (в т.ч. перехват управления).
omg, я же не говорю, что авторизация не нужна!
Я рассматриваю ядро как связующее звено между потребностями - запрсом и их удовлетворением - функционалом. Само ядро ничего делать не умеет, кроме как правильно адресовывать запросы, исходя их имеющихся в распоряжении расширений. Если библиотека авторизации присутствует, то она будет подключена и, соответственно, ее функции будут срабатывать на определенные события (в т.ч. перехват управления).
chaan
Guest
Вы почти не ушли от темы
Даже если нужно загружать каждый раз, то зачем прописывать в ядро функции оттображения. Ими и занимается API. В Винде эту функции частично выполняет Explorer, по-моему.
Вопрос: как Вы узнаете, можно ли смотреть определенному пользователь определенную страницу? Я думаю, что узнаете параметры страницы, касающиеся прав на её просмотр. Для этого нужно авторизироваться? Нет! Система может работать без авторизации? Да!
В ядро нужно пихать ИМХО то, без чего система работать не сможет. А вообще, в ядро можно напихать хоть код всех модулей, но это не очень хорошо... По этому и пишутся отдельные модули. Их проще сопровождать.
Если же касаться частной практики, то проекты вроде Комбатс пишутся индивидуально, и, скорее всего, я не видел, в них такое разделение, как описано выше.
И еще, такой структурой можно достигнуть бо`льшей маштабируемости, чем загрузкой всех модулей по умолчанию.
Даже если нужно загружать каждый раз, то зачем прописывать в ядро функции оттображения. Ими и занимается API. В Винде эту функции частично выполняет Explorer, по-моему.
Вопрос: как Вы узнаете, можно ли смотреть определенному пользователь определенную страницу? Я думаю, что узнаете параметры страницы, касающиеся прав на её просмотр. Для этого нужно авторизироваться? Нет! Система может работать без авторизации? Да!
В ядро нужно пихать ИМХО то, без чего система работать не сможет. А вообще, в ядро можно напихать хоть код всех модулей, но это не очень хорошо... По этому и пишутся отдельные модули. Их проще сопровождать.
Если же касаться частной практики, то проекты вроде Комбатс пишутся индивидуально, и, скорее всего, я не видел, в них такое разделение, как описано выше.
И еще, такой структурой можно достигнуть бо`льшей маштабируемости, чем загрузкой всех модулей по умолчанию.
Светлана PHP
Guest
Мил человек я и говорю: в ядро только самое необходимое. Что твоя CMS делает?
Позволяет управлять? просматривать?
Управлять кому угодно? просматривать кому угодно и всегда?
Ты будешь инклюдить свою авторизацию там, где нужно будет проверять а обладает ли пользователь Некий правом на удаление всего сайта и/или обладает ли пользователь Оригато возможностью редактирования страниц web-сайта - да везде ты бушь пихать свою авторизацию.
При этом определение уникальности пользователя, сессии тесно связано с запросом.
ЫМХО, блин!
Позволяет управлять? просматривать?
Управлять кому угодно? просматривать кому угодно и всегда?
Ты будешь инклюдить свою авторизацию там, где нужно будет проверять а обладает ли пользователь Некий правом на удаление всего сайта и/или обладает ли пользователь Оригато возможностью редактирования страниц web-сайта - да везде ты бушь пихать свою авторизацию.
При этом определение уникальности пользователя, сессии тесно связано с запросом.
ЫМХО, блин!
chaan
Guest
В чем плюс реализации в ядре над реализацией в модуле и последующем его подключении? Я думаю, разница не сильная. На самом деле все зависит от проекта. Если же подходить с позиции CMF, так сказать на перспективу, то такая отчужденность более оправданна.
Светлана PHP
Guest
Определение того, кто яляется клиентом в клиент-серверном приложении - задача №1. Всё остальное зависит от ссылки которая передаётся в Location хидерах запроса.
Ядро содержит класс, скажем USER который определяет всё необходимое для определения пользователя. Этот класс наследуется неким классом логики (пусть, AbstractController), который занимается представлением информации в зависимости от входящих данных класса HTTPRequest (он также подаётся на вход USER). Ну а дальше всё зависит какой скрипт и какого модуля унаследовал AbstractController.
![t3[0one]](/talk/data/avatars/m/0/739.jpg?1507973220){kind=avatar}