:) Неа, я просто веб-разработчик — фрилансер, который кучу заданий уже по этому движку выполнил. Да и с PHP5 давно общаюсь.
А за комплимент спасибо, это редкость в наших кругах.
Если будете делать __sleep, то помните — он должен вернуть все сериализируемые переменные. Если __sleep вернет null или false, то сериализация не пройдет — так как интерпритатор посчитает, что объект уже серриализован.
Не знаю, почему у вас так происходит, и, к сожалению, негде проверить. Сделайте «костыль». Тупо, конечно, но должно в вашем случае помочь — дополните определение той функции, о которой вы писали в топике до такого:
public function __call($sName,$aArgs) {
if(substr($sName, 0, 2)!='__')
return $this->oEngine->_CallModule($sName,$aArgs);
}
Сейчас негде проверить, но по идее это должно предотвратить перенаправления при обращении к магическим методам.
слип не находится в методах класса и вызывается как модуль
Вы уверены? Не определение __sleep в классе не должно приводить к ошибке. Так как это магический метод, и выполняется только тогда, когда он определен.
Вопрос: изначально предусмотренную в движке возможность кеширования посредством файлов как-то можно сделать рабочей на хосте с PHP 5+?
У меня на сервере стоит 5.3.0 — полет нормальный :)
Вопрос — как на PHP5 нормально настроить кеширование?
Учтите, что PHP5 не имеет нативного механизма кеширования. Любое кеширование, которое вы используете, создается с помощью: стандартных средств языка — чтение/запись файлов, либо интерфейса доступа (читай api) к специализированным программам кеширования данных (например, memcached). Поэтому ваш вопрос не очень понятен — разрабатывайте механизм (алгоритм) кеширования, если предложенный вас не устраивает, и формализуйте это в PHP5 код.
Как убрать все эти псевдо-нужные хуки (а они видимо здорово по коду раскиданы)?
Эти «псевдо-нужные», как вы выразились, хуки нужны для того, чтобы вызывать из любого action`a функции любого модуля. Например, экшн топика получает пользователя $this->User_GetUserById($sId) ну и дальше по сценарию. Но ведь, нельзя «зашить» все эти методы прямо в класс Engine, так как мы потеряем масштабируемость. Для перенаправления вызова используется магический метод __call.
Если такой подход вас не устраивает — могу предложить zend-стандарт, который часто используется при проектировании архитектуры с использованием Zend Framework — вы делаете основные функции модели статическими. И тогда обращаетесь к ним так: UserModel::GetUserById(). Плюсы и минусы статических вызовов — отдельная история и в комментарий не поместиться.
Да, но ведь в этом случае пользователь вообще не сможет зарегистрироваться. А человек справшивает,
чтоб простые юзеры не смогли писать топики, а только те, которым это разрешено
По хорошему, ACL должен быть не просто модулем дополнительным, а частью ядра. Хотя можно и модулем сделать, но тогда нужно будет в каждом Action вызывать и разбираться кому-чего можно, а кому нет.
Я понял вопроса. Это даже не вопрос. Это «мини-замечание» вам как разработчику. Вы ведь не сами все с нуля писали… А о тех, кто вам помог, можно и упомянуть.
Перелік країн на сторінці Люди прикольно виглядає :)
Маленький совет — если вы позиционируете ресурс как украино-язычный, то добавьте в него функционал, полезный именно для украинских разработчиков. Может модуль «Украинскии компании-разработчики», или блоги тех же Microsoft.Украина на государственном языке. Тогда украинский язык станет конкурентным преимуществом.
Я тоже сейчас столкнулся со сложностями проект менеджмента при организации онлайн сообщества. По своему опыту, могу сказать, что самое сложное здесь будет не ТЗ и поиск разработчиков — а работа с стартовым составом авторов.
А такой состав должен быть немаленьким, талантливым и харизматичным :) Желательно, разносторонне развитый и максимально широко разбросанный географически.
С самого начала их нужно «подсадить» на вашу идею, показать выгоды, «вдохнуть» в них командный дух, научить правильно всем пользоваться… Вот это проблемы. А сделать сайт (даже мощный медиа-центр) и нарисовать дизайн — в наше время не проблемы.
У меня вопрос к разработчикам бесплатных модулей такого плана — можно ли на основе ваших модулей выпускать свои версии. Т.е. если я возьму модуль АдминПанель и сделаю в ней более удобный интерфейс. Или допустим, сделаю дополнение, позволяющее прямо из админки управлять видом топиков на сайте.
Имеет ли такой модуль право на обособленное существование?
А за комплимент спасибо, это редкость в наших кругах.
Буду рад если мои советы чем-то вам помогли!
P.S. а коммент мой все равно заминусовали, странные тут порядки.
Сейчас негде проверить, но по идее это должно предотвратить перенаправления при обращении к магическим методам.
Вы уверены? Не определение __sleep в классе не должно приводить к ошибке. Так как это магический метод, и выполняется только тогда, когда он определен.
У меня на сервере стоит 5.3.0 — полет нормальный :)
Помагает увидеть где какие параметры.
По вашему примеру
localhost — домен
programs — action
codecs — event
1 — $this->GetParam(0)
Учтите, что PHP5 не имеет нативного механизма кеширования. Любое кеширование, которое вы используете, создается с помощью: стандартных средств языка — чтение/запись файлов, либо интерфейса доступа (читай api) к специализированным программам кеширования данных (например, memcached). Поэтому ваш вопрос не очень понятен — разрабатывайте механизм (алгоритм) кеширования, если предложенный вас не устраивает, и формализуйте это в PHP5 код.
Эти «псевдо-нужные», как вы выразились, хуки нужны для того, чтобы вызывать из любого action`a функции любого модуля. Например, экшн топика получает пользователя $this->User_GetUserById($sId) ну и дальше по сценарию. Но ведь, нельзя «зашить» все эти методы прямо в класс Engine, так как мы потеряем масштабируемость. Для перенаправления вызова используется магический метод __call.
Если такой подход вас не устраивает — могу предложить zend-стандарт, который часто используется при проектировании архитектуры с использованием Zend Framework — вы делаете основные функции модели статическими. И тогда обращаетесь к ним так: UserModel::GetUserById(). Плюсы и минусы статических вызовов — отдельная история и в комментарий не поместиться.
Странновато звучит :) Можно просто оставить количество в скобках (только пробелом отделить), и так понятно, что если 0 — значит отсутствуют.
По хорошему, ACL должен быть не просто модулем дополнительным, а частью ядра. Хотя можно и модулем сделать, но тогда нужно будет в каждом Action вызывать и разбираться кому-чего можно, а кому нет.
Я понял вопроса. Это даже не вопрос. Это «мини-замечание» вам как разработчику. Вы ведь не сами все с нуля писали… А о тех, кто вам помог, можно и упомянуть.
Маленький совет — если вы позиционируете ресурс как украино-язычный, то добавьте в него функционал, полезный именно для украинских разработчиков. Может модуль «Украинскии компании-разработчики», или блоги тех же Microsoft.Украина на государственном языке. Тогда украинский язык станет конкурентным преимуществом.
А такой состав должен быть немаленьким, талантливым и харизматичным :) Желательно, разносторонне развитый и максимально широко разбросанный географически.
С самого начала их нужно «подсадить» на вашу идею, показать выгоды, «вдохнуть» в них командный дух, научить правильно всем пользоваться… Вот это проблемы. А сделать сайт (даже мощный медиа-центр) и нарисовать дизайн — в наше время не проблемы.
Имеет ли такой модуль право на обособленное существование?