Каждый раз, когда вы получаете ...
"Warning: mysqli_fetch_object () ожидает, что параметр 1 будет mysqli_result, boolean задан«
blockquote>... это, вероятно, из-за проблемы с вашим запросом.
prepare()
илиquery()
могут возвращатьFALSE
(логическое), но это общее сообщение об отказе не оставляет вас в стороне от подсказок. Как вы узнаете, что не так с вашим запросом? Вы задаете !Прежде всего убедитесь, что сообщения об ошибках включены и видны: добавьте эти две строки в начало файла (ов) сразу после открытия
<?php
:error_reporting(E_ALL); ini_set('display_errors', 1);
Если ваше сообщение об ошибках установлено в php.ini, вам не придется беспокоиться об этом. Просто убедитесь, что вы обрабатываете ошибки изящно и никогда не раскрываете истинные причины каких-либо проблем для ваших пользователей. Выявление истинной причины для общественности может быть приглашением на золото с гравировкой для тех, кто хочет нанести вред вашим сайтам и серверам. Если вы не хотите отправлять ошибки в браузер, вы всегда можете следить за журналами ошибок веб-сервера. Расположение журналов будет варьироваться от сервера к серверу, например, на Ubuntu журнал ошибок обычно находится в
/var/log/apache2/error.log
. Если вы изучаете журналы ошибок в среде Linux, вы можете использоватьtail -f /path/to/log
в окне консоли, чтобы видеть ошибки, когда они происходят в режиме реального времени .... или как вы их делаете.Как только вы 'squared away на стандартном сообщении об ошибках, добавляющем проверку ошибок в вашем соединении с базой данных, и запросы дадут вам гораздо более подробную информацию о проблемах. Посмотрите на этот пример, где имя столбца неверно. Во-первых, код, возвращающий роковое сообщение об ошибке:
$sql = "SELECT `foo` FROM `weird_words` WHERE `definition` = ?"; $query = $mysqli->prepare($sql)); // assuming $mysqli is the connection $query->bind_param('s', $definition); $query->execute();
Ошибка является общей и не очень помогает вам в решении того, что происходит.
С помощью пары больше строк кода вы можете получить очень подробную информацию, которую вы можете использовать для решения проблемы сразу . Проверьте утверждение
prepare()
для правдивости, и если это хорошо, вы можете перейти к привязке и исполнению.$sql = "SELECT `foo` FROM `weird_words` WHERE `definition` = ?"; if($query = $mysqli->prepare($sql)) { // assuming $mysqli is the connection $query->bind_param('s', $definition); $query->execute(); // any additional code you need would go here. } else { $error = $mysqli->errno . ' ' . $mysqli->error; echo $error; // 1054 Unknown column 'foo' in 'field list' }
Если что-то не так, вы можете выплюнуть сообщение об ошибке, которое приведет вас к проблеме , В этом случае в таблице нет столбца
foo
, решение проблемы тривиально.Если вы выберете, вы можете включить эту проверку в функцию или класс и расширить ее, обработав ошибки изящно, как упомянутых ранее.
Я не хочу использовать какой-либо конвертер и JavaScript
blockquote>Здесь нет никакой магии. Вы должны написать код для выполнения задания. Я понимаю, что ваша забота заключается в том, что вы не хотите повторять одно и то же задание преобразования в каждом отдельном поле ввода.
В этом случае просто зарегистрируйте конвертер именно на
String.class
черезforClass
атрибут@FacesConverter
, как показано ниже.@FacesConverter(forClass=String.class) public class TrimConverter implements Converter { @Override public Object getAsObject(FacesContext context, UIComponent component, String submittedValue) { String trimmed = (submittedValue != null) ? submittedValue.trim() : null; return (trimmed == null || trimmed.isEmpty()) ? null : trimmed; } @Override public String getAsString(FacesContext context, UIComponent component, Object modelValue) { return (modelValue != null) ? modelValue.toString() : ""; } }
Таким образом, вам не нужно объявлять преобразователь в каждом отдельном поле ввода. Он будет применяться прозрачно для каждого значения модели
String
, у которого еще нет зарегистрированного явного конвертера.. Метод JavaScript не рекомендуется, поскольку он полностью работает на стороне клиента, и конечные пользователи могут легко отключить и манипулировать JavaScript. Конвертер JSF работает на стороне сервера, и его результат не управляется конечным пользователем.
Я считаю, что реальная проблема в другом месте. Я столкнулся с тем же самым в своих формах (используя postgresql и JSF 2.1)
Когда я создал поле типа «char (20)». В этом случае я получил ненужные пробелы в h: inputText .
Затем я изменил тип поля на «character changeing (20)». В этом случае в h не было пробелов: inputText .
Вот объяснение этого; Postgresql doc