Свой расчет рейтинга

Я понимаю, что есть, навеное, какие-то типовые схемы расчета рейтинга в подобных системах, которые были опробованы уже на различных ресурсах. Но время от времени вспыхивают дискуссии о том, что «я бы считал не так» или «я хочу ввести еще один параметр» и т.д. Отсюда предложение:

Желательно предусмотреть некий стандартный механизм, позволяющий подключать пользовательские модули расчета рейтинга (без использования «грязных хаков»). Или, как минимум, вынести коэффициенты расчета в некий конфиг. Тогда можно было бы, при желании, хотя бы этими коэффициентами играть, не влезая в исходники.

27 комментариев

avatar
можно будет переопределить модуль Rating, как и любой другой
  • ort
  • +1
avatar
Конечно, можно. Но потом надо все время помнить, что модуль переопределен, чтоб при апгрейдах ЛС ненароком не перезаписать его.
avatar
нее, переопределение будет происходить путем создания файла с новым классом с определенным названием, в LS такого файла не будет, следовательно при апдейте он никуда не денется
avatar
всёравно больше похоже на костыль :)
avatar
это не костыль, а практика фремворков
avatar
Не сказал бы. тыт палка о двух концах.
avatar
зы. да и вообще ничего против не имею, если вы уже взяли это на заметку.
avatar
ну да, лучший метод изменения логики — это правка существующего кода…
avatar
Макс, ведь мало новый модуль залить. Допустим, сделал я MyRating.class.php, там свой класс описал и т.д. Но ведь обращение из других скриптов будет к $oEngine->Rating_xxx(). Значит, надо и эти обращения переписать (напр., файл voteUser.php). Т.е. как минимум 4 файла надо отслеживать.
avatar
Тоже столкнулся с этим. Есть ли способ перекрыть класс модуля не меняя обращения к нему и не затрагивая ядро?
avatar
avatar
А, пардон, упустил из виду ключевое слово «будет». Тогда просто ждем-с…
avatar
обращения идут через обертку, поэтому ничего менять не нужно будет, достаточно переопределить необходимые методы и они автоматом подхватятся
avatar
в SVN появилась возможность переопределять модули. Например для переопределения модуля Blog создаем рядом файл Blog.class.custom.php с таким содержанием:
<?
/**
 * Модуль для работы с блогами
 *
 */
class LsBlog_custom extends LsBlog {	
		
	public function Init() {				
		parent::Init();
		var_dump("blog custom module");
	}	
}
?>
  • ort
  • +2
avatar
отлично отлично!
avatar
Движок с каждым днем становится все более гибким, значительно расширяются возможности его кастомизации, однако одновременно с этим тяжелеет его серверная сторона — дофига проверок на существование файлов, а каждая проверка — это обращение к супер-медлительной штуке под названием «файловая система»:)
Хотя результаты работы функции file_exists(...) и кешируются на время исполнения скрипта, планируется ли какая-нибудь оптимизация механизма выборной загрузки файлов?
avatar
Таков закон — или система узкоспециальна и быстра, или система универсальна и несколько медленней. Примером тому может служить Друпал. Хотя медлительность Друпала отлично преодолевается настройками хоста — кэширование статики, байт-кода и т.д. По части файловой системы, то тут скорее всего в качестве решения можно применить серверный вариант — кластеризацию. Как вариант — Кластер распределения нагрузки — все манипуляции с загружаемыми файлами отдать на такой кластер. При таком варианте придётся вносить значительные изменения и в сам двиг CMS, что в свою очередь уменьшит потенциальную аудиторию владельцев сайтов на LiveStreet.
avatar
ЗЫ Хотя-я-я-я-я… если удастся опционально «воткнуть» такую возможность (разносить CMS по разным серверам/кластерам) без значительных потерь в скорости на одном сервере (вариант для большинства), то это будет отличной мотивацией (на использование LiveStreet) — как в случае с TYPO3 (аналогия, хотя я и затрудняюсь утверждать то что там такое есть) люди иногда используют эту CMS просто по тому что она для о-о-очень крутых вариантов использования.
avatar
дофига проверок на существование файлов
почему дофига? проверка только в момент первого обращения к модулю, все остальные обращение уже не используют проверку
avatar
Если делать так, чтоб не сужать возможности, то я вижу только одну альтернативу — некий механизм «регистрации» модулей. Тогда ядро не будет обращаться к «супер-медлительной штуке» только для того, чтобы проверить — существует ли некий файл (или набор файлов), а будет сразу обращаться только к тем модулям, которые явно зарегистрированы.

ЗЫ Хотя я не знаю, какая доля времени от общего времени выполнения приходится на вызовы ф-ции file_exists(...). Если пара процентов, то это вовсе не критично.
avatar
лучше вопрос поставить так: что быстрее file_exists() или обращение к файловому кешу с запросом get()? Не думаю, что обращение к кешу быстрее, а ведь именно файловый кеш используется в большинстве систем на LS. А в 0.4 обращений к кешу стало на порядок больше.
avatar
добавлена возможность кешировать результат file_exists в памяти при использовании memcache
avatar
Макс, а что будет, если я положу рядышком не один, а пару файлов?
Например, Blog.class.custom1.php
class LsBlog_custom1 extends LsBlog { ... }

и Blog.class.custom2.php
class LsBlog_custom2 extends LsBlog { ... }
avatar
ничего не будет
avatar
А, так ключ в элементе названия custom? Должно быть обязательно ххх.class.custom.php? А я было решил, что просто наличие файла проверяется, а не его название.
avatar
ага, именно ххх.class.custom.php
avatar
Имхо это вполне логично и адекватно :)
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.