В LS появилась новая возможность для разработчиков плагинов — наследование классов. Идея была высказана еще avadim'ом здесь.
Эта возможность позволит удобно переопределять различные методы одного класса (модуля, экшена, сущности, маппера) разными плагинами без конфликтов.
Главное отличие от делегирование — не происходит блокировки переопределения класса для других плагинов. Также есть возможность переопределения одного метода разными плагинами, но здесь разработчикам нужно быть очень осторожными и делать так, чтоб свести вероятность конфликта к минимуму.

Как использовать.

Например, нужно переопределить метод получения пути до аватара у сущности пользователя в плагине Test. В плагине необходимо объявить те классы, которые будут наследоваться. Объявление происходит в свойстве $aInherits:

<?php
class PluginTest extends Plugin {
    
    protected $aInherits=array(
       'entity'  =>array('ModuleUser_EntityUser'=>'_ModuleSide_EntityUser')
    );

    public function Activate() {        
        return true;
    }
    
    public function Init() {        
    }
}
?>

Читать дальше

В LiveStreet 0.4 появилась возможность переопределять не только целиком модули, но и отдельные методы. Это позволить разным плагинам бесконфликтно переопределять разные методы одного модуля.

Принцип действия этого механизма основан на Hook'ах:

1. Вызов каждого метода сопровождается выполнением хуков — module_ModuleName_MethodName_before и module_ModuleName_MethodName_after, соответственно ДО и ПОСЛЕ вызова метода модуля. В первом случаи в хук передаются параметры вызова метода, во втором передается результат выполнения метода модуля.
2. На module_ModuleName_MethodName_before можно повесить специальный хук — delegate, результат выполнения которого и будет «результатом» выполнения метода модуля

Пример:

<?php 
class HookTest extends Hook {
	public function RegisterHook() {
		$this->AddDelegateHook('module_text_parser_before','testHook',__CLASS__,-3);
	}

	public function testHook($aVars) {
		return 'Topic text > '.$aVars[0];
	}
}
?>

Читать дальше

Решил не засорять топик с руководством по созданию плагинов, напишу тут, что нашел в процессе тестирования.

Итак, по порядку, что уже было:
1) (fixed) ошибка с определением названия экшена при делегировании: создал тикет
2) предложение об автоподстановке префиксов делегатов ( livestreet.ru/blog/dev_documentation/3710.html#comment59803, пункт 2 )
3) (fixed) отсутствие поддержки делегирования на основе данных из xml-файла (по-видимому, функция просто ещё в разработке)

И теперь ещё кое-какие мысли (пока все в файле /engine/classes/ActionPlugin.class.php).

— Сейчас, при делегировании экшена (например {plugin_dir}/classes/actions/ActionSettings.class.php) происходит автоматическое делегирование соответствующей директории темплейтов, что не очень хорошо, т.к. это совершенно необязательно по логике и придется тупо копировать всю папку actions/ActionSettings в плагин.
Сейчас там проверяется только наличие в плагине папки с соответствующим шаблоном:

$sTemplateName=in_array(Config::Get('view.skin'),array_map('basename',glob(Config::Get('path.root.server').'/plugins/'.$aMatches[1].'/templates/skin/*',GLOB_ONLYDIR)))
				? Config::Get('view.skin')
				: 'default';

хорошо бы проверять наличие папки с соответствующим экшеном:

$fGetTpl = create_function('$sPath','preg_match("/skin\/([\w]+)\/actions/i",$sPath,$aMatches); return $aMatches[1];');
$sTemplateName=in_array(Config::Get('view.skin'),array_map($fGetTpl,glob(Config::Get('path.root.server').'/plugins/'.$aMatches[1].'/templates/skin/*/actions/Action'.ucfirst($aMatches[2]),GLOB_ONLYDIR)))
				? Config::Get('view.skin')
				: 'default';

— В методе SetTemplateAction() код

$this->getTemplatePathPlugin().'/actions/Action'.ucfirst($aMatches[2]).'/'.$sTemplate.'.tpl'

в случае без делегирования вернет /actions/ActionSettings/profile.tpl, а надо actions/ActionSettings/profile.tpl, поэтому первый слэш переносим отсюда в getTemplatePathPlugin():

$sDir=Config::Get('path.root.server')."/plugins/{$aMatches[1]}/templates/skin/{$sTemplateName}/";

— Дублирование кода в GetTemplate() лучше заменить на

if (is_null($this->sActionTemplate)) {
    $this->SetTemplateAction($this->sCurrentEvent);
}

— В дополнение к первому:
Чаще всего нужно изменить не все шаблоны экшена, а только некоторые, зачем же копировать не измененные? Сделаем проверку, есть ли они в делегирующей папке, и, если нет, вернем стандартные:

protected function SetTemplateAction($sTemplate) {
if($sActionTemplate=preg_match('/^Plugin([\w]+)_Action([\w]+)$/i',$this->GetActionClass(),$aMatches)) {
      $sTplFile = 'actions/Action'.ucfirst($aMatches[2]).'/'.$sTemplate.'.tpl';
      $sActionTemplate = is_file($this->getTemplatePathPlugin().$sTplFile)
        ? $this->getTemplatePathPlugin().$sTplFile
        : $sTplFile;
    }
    $this->sActionTemplate = $sActionTemplate;
	}

Вот такие вот мысли.
Что скажете?

PS — также с нетерпением ждем описания функционала кастомных модулей.

Предисловие

Что такое плагины — читайте здесь.
По мотивам этого, выполняю обещание — привожу руководство как подобное сделать в виде плагина. Всех тонкостей в одной заметке не расскажешь, но основное постараюсь изложить.

Примечание. Долго не публиковал этот материал, держал в черновиках — на случай «мало-ли-что-измениться». Но думаю, кардинальных изменений в механизме плагинов в ближайшем релизе уже не будет.

Пошаговая схема:

Читать дальше

Безболезненное расширение функционала — достаточно проблематичный вопрос (под «безболезненностью» я понимаю весь спектр удобства для пользователей движка).

Я думаю, вы еще не забыли, что для добавления новых возможностей в версиях до 0.3.1 включительно используются Хаки и Модули. При этом установка любого стороннего творения дело достаточно хитрое и небезопасное, часто требующее ориентирования в архитектуре и особенностях движка. Для преодоления этих проблем в ядро v.0.4 была введена система плагинов:


К чему мы стремились создавая систему плагинов?

а) расширения функционала (плагины) можно просто установить и также просто убрать (а вдруг не понравилось), сложность этого процесса не зависит от количества расширений, разветвленности структуры их каталогов и т.д.;
б) установка внешних расширений (плагинов) не усложняет обновление основного ядра;



Для тех, кого заинтересовали подробности

В продолжении топиков LiveStreet как платформа для модулей и Тест хуков в движке появилась поддержка хуков.

Использовать можно так:
1. В любом месте(модуле, экшене) установить вызов необходимого хука на метод модуля

$this->Hook_AddExecModule('topic_show','Test_MyHookRun',10);

регистрирует на событие topic_show вызов метода MyHookRun у модуля Test с приоритетом 10.
2. В любом месте установить вызов хука на функцию

$this->Hook_AddExecFunction('topic_show','var_dump',-5);

регистрирует вызов функции var_dump
3. Создать класс хука в каталоге /classes/hooks/ с именем файла HookTest.class.php с содержанием

<? 
class HookTest extends Hook {	
	public function RegisterHook() {
		$this->AddHook('topic_show','testHookFunct',__CLASS__,-3);
	}
	
	public function testHookFunct($aVars) {
		var_dump("Hook it!");
	}
}
?>

Читать дальше

Господа, я накидал простейший механизм хуков. Предлагаю потестить его на производительность на рабочем проекте.


Читать дальше

Данный проект очень интересен для меня, так что я хотел бы внести посильную лепту в его формирование.

Итак, у меня появилось желание написать руководство по созданию своего вида топика. Такая операция может быть очень полезной и открывает более широкие возможности размещения движка.


Читать дальше

Есть у кого нибудь оригинальные идеи начисления силы пользователю и рейтинга комментам, топикам, блогам, юзерам?
Сила должна зависить от активности пользователя и от отценки его работ(топиков, комментов) другими юзерами. А дельта голосования за коммент, топик, блог, юзера должна зависить от силы голосующего. Как то так :)