Допустим я делаю какой-то свой шаблон contentYo и рендерю его в своем приложение так:

return $this->registry->getClass('output')->getTemplate('modcp')->contentYo();

 

Где-то в этом своем шаблоне я хочу подключить стандартный шаблон showCard (когда крусором на ник юзера наводишь - выскакивает окошко с его инфой)

Вставляю я его в свой шаблон так:

{parse template="showCard" group="какая-то_группа"}

Но в шаблон showCard нужно передавать переменные

$member, $download=0

.

И тут вопрос: эта переменная $member - это данные из таблицы с инфой юзеров. Эти данные я могу сам, вручную выбирать из таблицы и потом свой основной шаблон рендерить так:

return $this->registry->getClass('output')->getTemplate('modcp')->contentYo($member);

где $member - то, что я населектил вручную.

А в моем шаблоне contentYo подключать нужный мне шаблон showCard уже с указанием params="$member":

{parse template="showCard" group="какая-то_группа" params="$member"}

Так ведь?

 

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

Как мне самым кратким и разумным путем получать переменные для нужных мне шаблонов?)

Т.е. вы хотите, чтобы шаблоны сами запрашивали данные? У меня для вас плохие новости - это полное противоречие доктрине MVC, и стремление к нему почти всегда говорит о профессиональной непригодности программиста.

 

Четкое разделение логики и преставления - основа прозрачного, надежного и безопасного кода. Контроллер собирает, обрабатывает, модифицирует и пишет данные. Шаблон - лишь получает и выводит результаты работы. На этапе вывода шаблона все необходимые данные уже должны быть обработаны и подготовлены к выводу. Только так и никак иначе.

 

Кроме абстрактного:

каждый раз вручную выбирать из таблицы нужные данные для любого стандартного шаблона

какой реальный пример вы можете привести, когда на этапе отрисовки шаблона может потребоваться запросить какие-то данные из базы, что нельзя было подготовить еще до вызова этого шаблона?

 

IP.Board 3.x полностью переписан в соответствии с данными практиками, и потому хорош. Если вам тяжело разбираться в качественном коде и следовать общепринятым практикам - скачайте любой скрипт 5-7 летней давности, например, тот же IP.Board 2.3.6 (хотя там уже тоже есть зайчатки разума) - тогда еще повсюду был говнокод, и SQL-запросы вперемежку с echo "радовали глаз" всем и каждому :)

 

P.S. Если говорить о выборке данных пользователей, то там никакой рутины нет, есть удобный метод IPSMember::buildDisplayData().

Т.е. вы хотите, чтобы шаблоны сами запрашивали данные?

Да ну нет же, не хочу я этого. Я этого и не писал нигде.

и стремление к нему почти всегда говорит о профессиональной непригодности программиста.

Та не стремлюсь я к этому, да что ж такое. Вы меня уже называли говнарем. Я нигде не писал, что МВЦ говно!

 

какой реальный пример вы можете привести, когда на этапе отрисовки шаблона может потребоваться запросить какие-то данные из базы, что нельзя было подготовить еще до вызова этого шаблона?

Да ёмае, ну быть такого не может, у меня есть глаза, и я вижу, что я писал. В моем сообщении нету ни единого намека на все то, что вы мне написали.

Я не понимаю, как у вас получилось так трактовать мой вопрос, я бы в жизни не смог его так трактовать.

 

Следуя вашей логике вы мне отвечаете: "передать все нужные переменные в шаблон и затем отдать (отрендерить) этот шаблон - это говнокод, парень. Хотя ты совсем не про это спрашивал, но это говнокод, а ты сам знаешь кто".

 

Я описал обычную ситуацию, с которой вы 100 раз должны были сталкиваться. И противоречивость этой ситауции доктрине МВЦ - это как пчелы против мёда.

 

Опишу еще раз ситуацию.

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

{parse template="showCard" group="какая-то_группа"}

Так ведь?

Но тут вы сталкиваетесь с тем, что теперь в ваш шаблон нужно передать уже не не только ники юзеров (подшаблон showCard требует и другую инфу о юзерах). А именно, + ко всему, что вы передавали раньше (напомню, это только ники юзеров) передавать еще и все те данные, которые используются в шаблоне showCard. Я и спрашивал, нужно вручную смотреть, что за переменные в этом подшаблоне (например, там есть

$member['что-то']

) и ПЕРЕД выводом моего основного шаблона писать селект, что бы выбрать все нужные данные для подшаблона showCard или может есть какой-то готовый метод типа "выбрать из бд все нужные деанные для такого-то подшаблона"? А потом, когда все данные выбраны из базы, сформированы итд, передать в мой основной шаблон ВСЕ данные и "послать" этот шаблон на экран.

 

Я попытался ооочень подробно описать суть вопроса. Вопрос очень простой. И в нем НЕТУ НИЧЕГО того, про что вы мне написали выше. Увидеть и здесь

Т.е. вы хотите, чтобы шаблоны сами запрашивали данные?

и все, что вы мне написали - просто невозможно.

Воспринял поначалу ваши слова как "как мне получать дополнительные данные в самом шаблоне". После пояснения понял суть вопроса :)

 

Вы, видимо, плохо знакомы с документацией и API движка. Полный комплект данных для одного пользователя можно получить так:

 

$member = IPSMember::buildDisplayData( IPSMember::load( $member_id ) )

 

Обе функции есть по ссылке на документацию движка, что я привел в P.S. к своему посту.

 

IPSMember::load - находит и загружает данные пользователя:

        /**
        * Load member
        *
        * @param        string Member key: Either ID or email address OR array of IDs when $key_type is either ID or not set OR a list of $key_type strings (email address, name, etc)
        * @param        string Extra tables to load(all, none or comma delisted tables) Tables: members, pfields_content, profile_portal, groups, sessions, core_item_markers_storage.
        *                                      You can also use the aliases: 'extendedProfile', 'customFields' and 'itemMarkingStorage'
        * @param       string  Key type. Leave it blank to auto-detect or specify "id", "email", "username", "displayname".
        * @return      @e array   Array containing member data
        * <code>
        * # Single member
        * $member = IPSMember::load( 1, 'extendedProfile,groups' );
        * $member = IPSMember::load( 'matt@email.com', 'all' );
        * $member = IPSMember::load( 'MattM', 'all', 'displayname' ); // Can also use 'username', 'email' or 'id'
        * # Multiple members
        * $members = IPSMember::load( array( 1, 2, 10 ), 'all' );
        * $members = IPSMember::load( array( 'MattM, 'JoeD', 'DaveP' ), 'all', 'displayname' );
        * </code>
        */
       static public function load( $member_key, $extra_tables='all', $key_type='' )

 

IPSMember::buildDisplayData - подгружает к сформированному через load пользователю все данные для вышеупомянутых шаблонов:

        /**
        * Parse a member for display
        *
        * @param       mixed   Either array of member data, or member ID to self load
        * @param       array    Array of flags to parse: 'signature', 'customFields', 'warn'
        * @return      array    Parsed member data
        */
       static public function buildDisplayData( $member, $_parseFlags=array() )

 

Собственно, если бы вы не полагались на свои собственные выборки к таблицам, а всегда пользовались бы этими методами (как и было задумано разработчиками), то у вас бы этот вопрос вообще не возник :)

 

Старайтесь минимально спускаться до уровня запросов к БД. Они могут быть нужны разве что для каких-то ваших собственных нестандартных таблиц. Все, что есть в самом IP.Board, плотно охвачено представлениями. На любую операцию есть готовые интерфейс и представление. Это если вернуться к отчитыванию вас за MVC :3

Собственно, вот ссылка, которую надо внимательно изучить:

 

http://community.invisionpower.com/resources/documentation/index.html/_/developer-resources/api-methods/

 

Тут описана основная часть всего API: работа с пользователями, с аттачами, BBCode, поиском, письмами, аттачами и т.д., вплоть до работы по FTP с удаленным сервером :)

Вот. То, что нужно. Спасибо!

Но это методы только для получения данных о юзерах.

А если у меня, допустим, какой-то подшаблончик требудет данные такие как: название топиков, форумов, первый пост итд, то такие данные получать только вручную, через

$this->DB->build

Так ведь?

Так ведь?

Так.

Ну, можно использовать класс topics:

 

$classToLoad = IPSLib::loadLibrary( IPSLib::getAppDir( 'forums' ) . "/sources/classes/topics.php", 'app_forums_classes_topics', 'forums' );
$topics = new $classToLoad( $this->registry );
$topic = $topics->getTopicById($tid);
$post = $topics->getPostById($pid,$checkArchived=true);

$my_last_5_topics = $topics->getTopics(array('member' => $this->memberData, 'limit' => 5, 'offset' => 0, 'sortField' => 'date', 'sortOrder' => 'desc'));
$my_last_5_posts = $topics->getPosts(array('member' => $this->memberData, 'limit' => 5, 'offset' => 0, 'sortField' => 'date', 'sortOrder' => 'desc'));

 

Но тут уже, конечно, все зависит от конкретных задач - иногда проще и производительнее свои запросы с JOIN-ами составить :)