Всем привет! Я сейчас в поиске нового движка для своих разработок. С опенсорными php-движками как-то грустно все сейчас. Активно развиваются фреймворки, а КМС или совсем хилые, или очень устаревшие. Drupal 8 не оправдал надежд. Собирался даже свой движок писать, от отчаянья.
Случайно наткнулся на Ливстрит. В целом нравится. Хоть и плохо, что нет поддержки современных стандартов PSR. Но есть некоторые базовые вещи по структуре, которые не очень понятны. И прошу пояснить, кто может, или накидайте ссылок, где можно почитать, честно искал но не нашел.

Вот есть архитектура MVC. Про V и C я понял, V — это модуль на базе Smarty, а C здесь называются ActionXXX. А вот с M не очень понятно. Есть ModuleXXX, MapperXXX и EntityXXX. Это все к модели относится? А зачем тогда такое разделение было задумано? Наверно есть, какие-то причины?

И еще посоветуйте где почитать про ORM. А то нашел много статей про это на сайте, но хочется с самого начала понять как работат. Мне нравится как в yii это сделано. Но здесь сильно отличается.

Добрый день!

Хочу поделиться небольшим скриптом и услышать мнения)

За основу очередного своего проекта решил взять LiveStreet FW. С толкнулся с проблемой что приходится писать много однообразного кода.
Читать дальше →

Приветствую, уважаемые. Помогите, пожалуйста, разобраться с некоторыми вопросами в работе движка. Пишу плагин, и все вроде бы отлично, но как только дошел до работы с бд, — возникли трудности. Суть приблизительно такова: плагин добавляет новую страницу(ивент) на блог(тут проблем нет), на этой странице форма, с уже знакомыми полями(да не обязательно эти): название блога, заголовок, Текст, метки… Далее, в Ивенте эещена проверяю, передал ли _POST(на самого себя), и если данные корректные, с помощу модуля, хочу добавить их в БД движка. Конечно, это можно решить простыми простыми запросами еще в ивенте экшена, но хочется сделать как положено — через маппер, и сущности. Так вот, я к чему веду — не могу понять, как из массива _POST сформировать сущности, которые и будут отправляться и получаться из/в БД. Как формируется массив _aDate? не пойму взаимодействия сущностней и мапперов в модели?
Если, есть минутка, помогите, пожалуйста, — можно просто теорию…
Прошу не отправлять читать мануали по плагинам, и движку — уже все от штудировал. Спасибо.

Столкнулся с такой ситуацией.
1.Из базы получаю список топиков.
2.Передаю их в сущность и экшен

	public function GetTopicBlog($iPage,$sBandsName){
		$sql= "SELECT ".Config::Get('db.table.bands_topic').".*,".Config::Get('db.table.bands').".bands_id,".Config::Get('db.table.bands_blog').".blog_id 
		FROM ".Config::Get('db.table.bands_topic').",".Config::Get('db.table.bands').",
		".Config::Get('db.table.bands_blog')."
		WHERE ".Config::Get('db.table.bands').".bands_url='".$sBandsName."' 
		AND ".Config::Get('db.table.bands_blog').".bands_owner_id=".Config::Get('db.table.bands').".bands_id 
		AND ".Config::Get('db.table.bands_topic').".blog_id = ".Config::Get('db.table.bands_blog').".blog_id";
		
		 if ($aRow=$this->oDb->select($sql,$sBandsName)) {
		
		 return  Engine::GetEntity('PluginBands_ModuleBlogbands_EntityBlogbands',$aRow);
         }
	}

class PluginBands_ModuleBlogbands_EntityBlogbands extends Entity {
    public function getTopicId() {
        return $this->_aData['topic_id'];
		
    }
    public function getTopicTitle() {
        return $this->_aData['topic_title'];
    }
}

	$aResult=$this->PluginBands_ModuleBlogbands_GetTopicBlog($iPage,$sBandsName);
	$this->Viewer_Assign('aTopics',$aResult);

	{foreach from=$aTopics item=oTopic}   
         {$oTopic->getTopicTitle()}
        {/foreach}

И вот тут проблема. Цикл не работает. И список тайтлов топиков не выводит.
Как с этим быть?

Содержание $aResult при выводе в экшене

PluginBands_ModuleBlogbands_EntityBlogbands Object ( [_aData:protected] => Array ( [0] => Array ( [topic_id] => 1 [blog_id] => 3 [user_id] => 1 [topic_type] => topic [topic_title] => Мэр Костромы Александр Кудрявцев досрочно сложил полномочия [topic_tags] => Кострома,депутат,повительство [topic_date_add] => 2011-02-16 09:41:09 [topic_date_edit] => 2011-02-16 21:31:33 [topic_user_ip] => 46.42.30.223 [topic_publish] => 1 [topic_publish_draft] => 1 [topic_publish_index] => 1 [topic_rating] => 1.000 [topic_count_vote] => 1 [topic_count_read] => 48 [topic_count_comment] => 5 [topic_cut_text] => [topic_forbid_comment] => 0 [topic_text_hash] => 4adad33714c3a90f89d375ff148be29a [bands_id] => 5 ) [1] => Array ( [topic_id] => 2 [blog_id] => 3 [user_id] => 1 [topic_type] => topic [topic_title] => Костромичи стали лучшими в экстремальных прыжках на велосипедах [topic_tags] => Кострома,победа,прыжки [topic_date_add] => 2011-02-16 09:41:59 [topic_date_edit] => 2011-02-16 21:31:06 [topic_user_ip] => 46.42.30.223 [topic_publish] => 1 [topic_publish_draft] => 1 [topic_publish_index] => 1 [topic_rating] => 0.000 [topic_count_vote] => 0 [topic_count_read] => 15 [topic_count_comment] => 0 [topic_cut_text] => [topic_forbid_comment] => 0 [topic_text_hash] => 65fd9d8ac97a45311458756583048948 [bands_id] => 5 ) ) )

Это здорово, что в версии 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];
  }
}

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