Всем привет,
нужно тупо вывести таблицу из БД на страницу, подскажите как попроще это сделать?
Почему такая пхп вставка на странице возвращает Array (код из примера на стороннем ресурсе), как такой запрос вывести ввиде таблицы?
<?php
$query = db_query("SELECT * FROM {node} WHERE nid IN (1)");
$output = $query->fetchAll();
return $output;
?>
Комментарии
Потому что эта вставка, действительно, возвращает массив.
В идеале, вам надо этот массив скормить функции темизации.
К коду прикладывается картинка и на ней все ок, единственное, это код из модуля примера, но сам модуль который целиком доступен для скачивания кладет сайт а в логе ошибка типа:
kint($output); метод неизвестен
Предполагаю что это опечатка.
Большая просьба, напишите простенький пример с темизацией.
Вот элемент формы - таблица:
$form['status_table'] = array(
'#theme' => 'table',
'#header' => $header,
'#rows' => table_rows_data(),
'#empty' => t('No content available.'),
'#title' => 'Статус',
'#prefix' => '
'#suffix' => '
',
'#weight' => 7,
);
Вот функция, которая возвращает массив строк для построения таблицы:
function _table_rows_data() {
$query = db_query("SELECT * FROM {node} WHERE nid IN (1)");
$rows_data = $query->fetchAll();
return $rows_data;
}
Это как пример. Хотя есть еще куча вариантов.
С таким sql запросом проще Views использовать
да я чот потыкался - не понял как это сделать, хотя видел немного инфы про это, если дадите хорошую ссылочку что почитать буду благодарен.
> Почему такая пхп вставка на странице возвращает Array (код из примера на стороннем ресурсе), как такой запрос вывести ввиде таблицы?
Потому что такой у нее формат ответа - массив объектов, в виде таблиц можно вывести через theme_table
На код
$nodes = db_select('node', 'n')->fields('n', array('nid', 'type'))->orderBy('n.nid')->execute();
$header = array('Nid', 'Type');
$rows = array();
foreach ($nodes as $node) {
$rows[] = array($node->nid, $node->type);
}
$output = theme('table', array('header' => $header, 'rows' => $rows));
return $output;
а так же на theme_table
Пишет в лог -
Это я все же делаю что то не правильно или пхп фильтр балует?
PHP-фильтром правильно не может быть априори.
Давайте лучше учить вьюсы.
Опишите точнее какая вам выборка нужна
У меня своя кастомная таблица, в ней есть текстовые поля, цифровые и время, покажите на примере любой типовой таблицы а дальше думаю сам справлюсь (ну пусть будет таблица ноде или юсерс...)
С MySQL запросами - дружу хорошо, тут сложность для меня именно вывести это.
Во-первых, не theme, а \Drupal::service('renderer')->render().
Во-вторых, не помешало бы удосужиться заглянуть в структуру переменной, прежде чем выводить её на экран
"подход" с кастомной таблицей вкорне не правилен.
Простейший вариант - создать специальный тип ноды с нужными полями, и работать с ним стандартно. (вывести данные при помощи модуля views и т.п.)
Если кастомная таблица уже с данными (досталась по наследству), импортировать данные в созданную выше ноду.
таблиц 60 штук) с столбцами от 5 до 20)
вообще не думал что с выводом будут какие то проблемы, самое обидное что сделал типа макет обычными запросами mysql на php страницах, там все работает, придумал костыль - выводить это через фрейм, но ппц как свербит от такой реализации
Что конкретно у вас работает? Прямо вот так сразу через принт выводили результат запроса? Крайне сомнительно.
Выложите тот код, который работает в ваших макетах, а мы расскажем, как это воткнуть в друпал.
Грубо говоря, в Drupal 8 нет понятия "таблица БД".
Есть понятие Entity (сущность) , т.е. некий объект данных, поля которого в привычном понимании - поля таблицы БД, а методы - функции каких либо манипуляций с этим объектом, как стандартные (save и т.п.), так и определенные разработчиком.
Для хранения и обработки данных можно использовать:
1.Стандартные сущности Друпал (node, taxonomy term, user и т.п.).
2.Можно добавлять кастомные сущности с необходимым набором полей (таблицы в БД для этих сущностей друпал создаст сам).
3.Можно добавить кастомные сущности для имеющихся "самопальных" таблиц .
4.Можно добавлять кастомные сущности, данные которых вообще могут храниться где угодно: в файлах, отдаваться на запросы к внешним сервисам и т.п.
т.е. непосредственно работа с БД производиться на более низком уровне, а у разработчика есть весь нужные высокоуровневый инструментарий для работы с данными:
- создать сущность
- загрузить сущность
- сохранить сущность
- сделать выборку сущностей по определенным критериям
- и т.п.
Но как я понял, Вам пока будет достаточно просто блоков.
- Разместить кастомный блок в нужном месте нужной страницы
- Сделать выборку данных из БД
- Сформировать html-вывод
- Вывести результат в блок.
https://drupalfly.ru/lesson/drupal-8-programmnoe-sozdanie-bloka
Если так судить, то и в 7 друпале типа тоже не было таблиц. На самом же деле всё не так. Таблицы есть. Есть механизм запросов к этим таблицам, значит сущности по определению не обязательны, а яаляются лишь правилом хорошего тона. Но и то не всегда. Для сущности должны быть определены механизмы CRUD-операций. Это не в друпале, а вообще в принципе в программировании, безотносительно языков, фреймворков и т.п. И в этом контексте вовсе необязательно, чтобы строки любой таблицы были сущностями. Всё зависит исключительно о того, какие данные лежат в таблице, откуда они там берутся, как часто обновляются и т.д. Допустим, есть таблица почтовых индексов какой-то страны, такие данные импортируются из стороннего источника и не нуждаются в регулярном обновлении, делать под это дело сущности - вредительство, т.к. если надо отобразить список индексов, то с точки зрения потребляемых ресурсов выгоднее оперировать простым массивом из строк и чисел, чем создавать в памяти сотни и тысячи объектов сущностей.
Если необходимо отобразить список индексов, который меняется пару раз в год , то его надо доставать из кэша..
А если над этими данными соорудить кучку самопальных велосипедов в виде форм-страниц отображения данных, связей этих данных с другими сущностями, вывода этих данных во вьюсах с самопальными фильтрами и т.п. вещами, которые уже давно реализованы в Drupal для стандартных сущностей, то вот это самое и будет настоящим вредительством-)
А поддерживающий впоследствии весь этот зоопарк разработчик с первой зарплаты наймет киллера-)
Оно вам надо?-)
Когда я приводил пример с почтовыми индексами, я не думал, что всё может быть так запущено)))
Задача стояла достаточно сложная, нужны были ссылки - переходы между "таблицами", некоторые таблицы бд требовалось сливать в одну, слишком большой пример нужно показывать.
грубо говоря - инклудом, закинул в папочку отдельную php файлики свои и через пхп фильтр дергаю их.
НО
Я справился!!!!
Благодарю всех за участие!
Всё, что хорошо кончается - хорошо-)
Но Вы всетаки подтяните теорию "сборки" вэб-приложений на drupal и Drupal API.
Больше чем уверен, большинство ваших "трудных задач" решаются в пару-тройку десятков кликов-)
А как утверждают некоторые уважаемые люди: лучший код тот, который не пришлось писать.