Посидел, подумал пару месяцев на работе... На днях состоялся разговор с начальством о разработке проприетарной CMS, собрали список технологий и фреймворков, которые будут закладываться в основу. Что-то посоветовал я, что-то мне навязали, о чём-то я наверняка вообще не знаю, поэтому как руки дошли, всё в список собрал и решил посоветоваться. Может что-то из этого списка лучше заменить. Итак: Язык: php5+ / cgi Нативная кодировка: UTF-8 - через тесное взаимодействие с библиотекой UTF-8 (разработчик Rin (dkLab)) Архитектура: модульная, ООП Защита скриптов: IonCube (не накрываются ионкубом только сторонние библиотеки и модули, если этого пожелал разработчик модуля) Серверная база: apache+nginx / apache БД: абстрагировано через PDO (изначально рисоваться всё будет под MySQL) Для супербыстрой работы нагруженных участков есть рекомендация использовать Redis. Как это потом совмещать-то?... API (CMS<->внешка): абстрагировано через SOAP Файловый API (CMS<->внешка): cURL Модульный API (CMS Core <-> CMS Module): через методы родительского класса Проверка лицензии: взаимодействие с центральным сервером через SOAP Система обновлений: через cURL Панель администрирования: на базе Ext JS Интегрированный шаблонизатор: Smarty Криптозащита: на основе mCrypt Внутренняя синхронизация компонентов: эмуляция event-модели Внутренняя система тестирования: PHPUnit Документирование: скелетное, PHPDocumentor Другое: каскадная обработка ошибок средствами php, выброс ошибок по исключению Как-то вот так получилось... Всякую мелочевку уже не берусь описывать - это уже дело техники
если начальство отмахивалось полгода, а потом дало добро (причём сами пришли и сказали, что нужно вот такое), значит появился заказчик. кто именно - меня не должно интересовать. меньше знаю - крепче сплю
я не про заказчика, а про подход с соапами для связи цмски с хз чем, и курлом для связи цмски с файлами - это капец а не цмс. но оправдано в случае если надо очень-очень защититься даже от собственной цмс.
модули хз откуда приходящие. вот и получается, что для того, чтобы обеспечить адекватное поведение системы независимо от того, куда её имеют, приходится принимать таблетки для усиления паранойи
titch ну тоесть пофиг какое говно откуда кто взял, главное - мы обеспечим безопасность, а админ сайта пусть пихает любые модули какие в голову взбредет? э... бред это, чувак. =) это реальнейший бред. не надо писать продукт, рассчитаный на все случаи жизни - говно выйдет. а давайте сделаем спортивную машину с охуенной проходимостью на огромных таких колесах, чтобы был болшой кузов как у самосвала и туалет с бассейном. да! сорвем банк!
боюсь, что я не смогу переубедить) идея в том, что надо сделать пуленепробиваемое ядро, которое будет работать 100% по лицензии. и если есть обновление системы, то оно должно проходить строго в соответствии с лицензионным соглашением. обновление модулей через курл по той же причине. вышла новая херня, не заплатил - гуляй. заплатил - получи и распишись. поставил со стороны - развалилось - гуляй. поставил из репозитория и развалилось - разработчик несет какую-то ответственность. тут замес уже не в том, кто лучше или хуже напрограммил, а в том, кто должен №;%:?* получить за то, что сделал
Разработка PDO заморожена ЕМНИП, юзайте mysqli Систему обновлений - через SOAP! Каждому модулю - отдельный класс-драйвер для работы с БД, со специфичными для модуля задачами. А уже драйвер реализует работу с MySQL или Redis. Естественно, никаких SQL или redis запросов вне драйвера.
с этого места по подробнее учту т.е. фактически получается, что класс-драйвер - это и есть модуль, только он единственный, кто работает с Redis напрямую. верно?
Да, Битрикс это вещь! Как его не настраивали, а все равно умудрялся валить наш сервак с 24Гб оперативки titch, правильно. Основательно сделаете, основательно заработает!
тут недавно сайтик открывался известной организации. в момент открытия повалили люди , человек так думаю под 300-400 , не более. сайт 10 мин в оффе и так ещё раза 2. потом регаюсь на нём , мне приходит линк подтверждения мегакривой , я его руками фиксил , потом логинился с 3его раза , а потом уж психанул и нажал ctrl+u и всё осознал =) битрикс! ))
Кроме того, что последняя версия вышла 1 мая 2006 - ничего сказать не могу) Это просто как более логичный вариант - и сервером обновлений удобно будет управлять, и архитектура клиента проще. Смотря что вкладывать в понятие "модуль", но в целом - да.
Вообще я скептически отношусь к тому, чтобы использоваться SOAP для обновлений. Согласен в том, что через него можно гонять всякую инфу, которая даст понять клиенту, что обновление необходимо, а серверу - что клиент имеет право на это обновление. Но реально сам модуль (файл) лучше отдать через cURL, а не заниматься конвертированием в фиг пойми что, а потом на стороне клиента это восстанавливать в файл
пруфлинк: http://pecl.php.net/package/pdo ядерная часть PDO активно развивается. последний бакфикс позавчера был: http://bugs.php.net/search.php?cmd=disp ... ckage_name[]=PDO+related
точняк.. там же группы по 6 бит. прирост 2 бита на 6 бит... а у меня в голове почему-то высплыло 2 бита - это 2^2 =) на на счёт не больше, как раз таки больше 33,(3)%
titch неожиданно )) (про pdo) А там чо в base64, скрипты да может немого графики - все это в zip и в теле xml ответа soap - норм!
titch но все равно не надо им =) это изврат хотя можно пгп шифрование забубенить ваще будет супа крута
SOAP и с SSL работает. Если вам надо контролировать доступ к обновлениям, то тогда надо генерировать уникальный url для авторизированного юзера и для каждого обновления. Т.е. лишняя запись в БД или еще куда-нить + лишний скрипт для отдачи файла. А если юзать SOAP, не надо. Хотя вопрос конечно совсем не принципиальный )))