Так и не удалось получить желаемого поведения от этой модели. Есть родительская сущность А, в ней несколько дочерних Б. Всё. Вложенность закончилась. Получить список сущностей А с вложенными сущностями Б. Такое в данный момент получить в принципе возможно или здесь метод в модуле придётся писать ручками?
Омг. На мой вкус, стандарт именования в LiveStreet несколько отличается от PEAR'овского. Так что эта дока хоть и хороша, в данном случае, не актуальна.
Попробовал поменять родителей для всех классов модуля User — нашёл багу.
Если первичный ключ содержит символ нижнего подчёркивания, получается такая конструкция User_ModulegetUserItemsByArrayUser_Id. Исправил в Engine формирование этой строки (вставил явно слово Module), стало получаться, на первый взгляд, правильно — ModuleUser_getUserItemsByArrayUser_Id.
Далее Engine::GetClassInfo() неправильно разбирает эту строчку и Engine::_CallModule пытается вызвать метод id модуля User.
Я так понял, планируется перевод модулей-мапперов-сущностей на ORM? Ну поменяю я локально наследование не от Entity, а от EntityORM, потом обновлю и снова менять…
Стоило мне убить день и разобраться, как появился материал. Спасибо за труды.
Тот пример со статьями плохо работает с текущей версией движка из репозиория? Пока не понял, как заставить его работать без ошибок, но ошибка уходит, если убрать связь с юзером (что понятно). Так понимаю, ещё способ — унаследовать ModuleUser_*User в движке от ORM версий абстрактных классов?
Всё очень интересно. В плагин Кошелёк нужно вносить какие-то изменения для работы с ним других плагинов? Насторожила фраза «плагин в ближайшее время будет интегрирован с «Объявления» от Ajaxy». То есть в код Кошелька будут вноситься изменения чтобы связка заработала или всё же Объявления будут использовать апи кошелька?
Добавить бы возможность прикреплять файлы к статическим страницам и возможность поддержки этого функционала другими плагинами и можно будет думать о покупке. Не планируется такой функционал?
Думаю, не лишним будет здесь озвучить, как будет производиться рассылка-получение обновлений. Нужно ли писать об этом лично или будет рассылка новой версии?
Так ли необходимо шкурить админку? Это служебный раздел. Имхо, можно использовать стандартную тему.
А про новый вид топика не понял. Мне кажется, нужно только поставить хук в стандартный шаблон вывода топиков и сделать соответствующий плагин. Об этом создал тикет в трэке. Наследование же должно решить всё на уровне логики. С этой частью пока только разбираюсь, но думаю, что если уж добавлять виды топиков, то по-умному, с возможностью расширения плагинами, а не хаками.
Выше было упоминание о добавлении хука «topic_action_menu» — можно будет добавлять свои кнопки в меню создания топика. А как насчёт вывода этих самых топиков? То есть, нужны хуки в topic_list.tpl внутри цикла foreach.
Вообще, я пока не уверен, останется ли сам дампер в поставке или я дам отдельно ссылку на его загрузку. А вообще, у меня на продакшене .htaccess такого содержания стоит. Даже ума не приложу, зачем там кнопка «Скачать».
Из чтения документации mysql, я понял, что даты там хранятся не в unix-time, а в каком-то таком виде
'0000-00-00 00:00:00'
. Ну и напрямую сравнить например
{$oTopic->getDateAdd()}
и
{$smarty.now}
нельзя.
Но плагин прекрасно понимает и timestamp
Гм. Посмотрю внимательней. Но при попытке скормить ему результат функции strtotime() я получил 1 января 1970 года. Обновлю этот момент до версии из транка.
Вот этого замечания тоже не понял
А это был не на date_format наезд, а на такие конструкции
strtotime($oTopic->getDateAdd())<$smarty.now
в шаблоне.
:
This allows template designers to use the date_format modifier for full control over date formatting, and also makes it easy to compare dates if necessary.
Вот о чём я.
Я бы предложил сделать везде вот так:
public function getDate() {
return strtotime($this->_aData['date']);
}
и сеттеры соответственно изменить.
Плагин date_format специально разработан для этого движка
Я здесь написал псевдокод. Если Get так мозолит глаза, можно его убрать в данном примере.
Проблема не в этом.
Или записать вот так:
$aСписокСущностейБ = $aСписокСущностейА[0]->GetСписокСущностейБ();
$aСписокСущностейБ[1]->getTitle();
Как настроить $aRelations чтобы получить такую структуру?
Код хочу получить примерно такой
Раскуривание исходников в полной мере не проясняет вопроса.
Спасибо.
Я не отрицаю, не должен. Но бага всё-таки есть. Не я же генерирую вызов этого метода. Вопрос открыт.
Если первичный ключ содержит символ нижнего подчёркивания, получается такая конструкция User_ModulegetUserItemsByArrayUser_Id. Исправил в Engine формирование этой строки (вставил явно слово Module), стало получаться, на первый взгляд, правильно — ModuleUser_getUserItemsByArrayUser_Id.
Далее Engine::GetClassInfo() неправильно разбирает эту строчку и Engine::_CallModule пытается вызвать метод id модуля User.
Тот пример со статьями плохо работает с текущей версией движка из репозиория? Пока не понял, как заставить его работать без ошибок, но ошибка уходит, если убрать связь с юзером (что понятно). Так понимаю, ещё способ — унаследовать ModuleUser_*User в движке от ORM версий абстрактных классов?
Думаю, не лишним будет здесь озвучить, как будет производиться рассылка-получение обновлений. Нужно ли писать об этом лично или будет рассылка новой версии?
Прошу простить, если информация пробегала.
А про новый вид топика не понял. Мне кажется, нужно только поставить хук в стандартный шаблон вывода топиков и сделать соответствующий плагин. Об этом создал тикет в трэке. Наследование же должно решить всё на уровне логики. С этой частью пока только разбираюсь, но думаю, что если уж добавлять виды топиков, то по-умному, с возможностью расширения плагинами, а не хаками.
Согласен, надо добавить.
А это был не на date_format наезд, а на такие конструкции в шаблоне.
:Вот о чём я.
Я бы предложил сделать везде вот так:и сеттеры соответственно изменить.
То есть, это не из стандартной поставки Smarty?