Всем доброго времени суток.
Есть замечательное руководство Как создать свой вид топика, используя систему плагинов.
Однако, у меня есть необходимость переопределить еще и стандартный энтити класс, через плагин. Подскажите как это сделать?

Спасибо пользователям gran , beauty_free

никак не пойму как работать с entity

в мапперах описал 2 селекта

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

Хочу предложить свои идеи для развития MVC/ORM.

Замечу, что исторически сложилось так, что MVC в LiveStreet весьма отличается от привычного представления в других фреймворках.
Модель здесь заменяется связкой модуль+сущность+маппер, причем, если сущность представляет из себя стандартный ООП-объект с набором свойств и методов, то модули и мапперы, это просто наборы функций для работы с определенными типами данных, что скорее похоже на библиотеки из структурного программирования, чем на стандартный ООП.
Я не возьмусь судить хорошо это или плохо, у меня есть лишь предложения о том, как можно воспользоваться этим для создания эффективных отношений между объектами (модулями).


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

Это здорово, что в версии 0.4.* появилась возможность автоматического доступа к полям модели из записи в БД, без постоянного прописывания get- и set-методов в файле *.entity.php.

Однако при попытке воспользоваться новым функционалом сразу столкнулся с проблемой:
Т.к. по логике, принятой в LS, все поля записываются в базе данных с префиксом (имя модели), то и автоматические геттеры теперь требуют имени модели.
Иначе говоря, если у нас есть модуль Test с таблицей prefix_test и полем в таблице test_name, то чтобы получить к нему доступ, нам нужно писать $oTest->getTestName() вместо привычного способа $oTest->getName(), который является логичным и удобным.

Я считаю, что необходимо ввести поддержку обоих вариантов, не только по причине неудобства варианта, который возможен сейчас, а еще и по более важной причине — совместимости.
Исторически в самом LiveStreet все методы были прописаны в *.entity.php и указывались без имени модели, например для блога — getDescription(), getTitle() и т.д., а никак не getBlogDescription() и getBlogTitle().

Подобный принцип наименования (вполне логичный и разумный) наследовали большинство модулей и плагинов, которые существуют на сегодняшний день, поэтому было бы совсем не разумно использовать половину методов (которые уже прописаны в *.entity.php) в одном виде, а другую половину, которая будет добавляться вместе с новыми свойствами моделей — в другом.

Предлагаю простой вариант, как исправить эту ошибку:
в /engine/classes/Entity.class.php, в методе __call()
после блока

if (isset($this->_aData[$sKey])) {					
  return $this->_aData[$sKey];
}

добавить блок

else {
  preg_match('/Entity([^_]+)/', get_class($this), $sModulePrefix);
  $sModulePrefix = strtolower($sModulePrefix[1]) .'_';
  if (isset($this->_aData[$sModulePrefix . $sKey])) {					
    return $this->_aData[$sModulePrefix . $sKey];
  }
}

На мой взгляд, это намного упростит и упорядочит работу с свойствами моделей.

Привет.
Хочу сделать плагин для аватаров, не получается переопределить стандартный метод.
Последовательность действий:
1) в паке MyPlugin создал файл MyPlugin.class.php

class PluginMyPlugin extends Plugin {
   protected $aDelegates=array(
      'entity' => array('UserEntity_User'=>'PluginMyPlugin_UserEntity_User')
   );
}

2) в папке плагина создал файл classes/module/user/entity/User.entity.class.php

require_once(Config::Get('path.root.server').'/classes/modules/user/entity/User.entity.class.php');

class PluginMyPlugin_UserEntity_User extends UserEntity_User {
    protected function getProfileAvatarPath() {
        echo 'test';
        }
    }
}

Разрабатывая свои модули для движка, столкнулся с большим количеством сущностей с единообразными методами setVar() и getVar(), тело которых состояло из одной строчки:

    public function getId() {
        return $this->_aData['id'];
    }

    public function setId($data) {
        $this->_aData['id']=$data;
    }

В связи с этим дописал перегрузку методов у класса Entity:


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

Вступление

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

Хранилище данных настроек

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


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