Comments 19
Почему нельзя в родной функции getParam провести аналогичное приведение типов?
а-ля:
return isset($_GET[$name]) ? $_GET[$name] : (isset($_POST[$name]) ? $_POST[$name] : $defaultValue);
а-ля:
return isset($_GET[$name]) ? (ctype_digit($_GET[$name]) ? (int)$_GET[$name] : $_GET[$name]) : (isset($_POST[$name]) ? (ctype_digit($_POST[$name]) ? (int)$_POST[$name] : $_POST[$name]) : $defaultValue);
А суть в том, что для mysql нет разницы [select * from data where id = 1] или [select * from data where '1'].
Это опечатка, или я чего-то не понимаю?
В первом случае вернет запись с id=1, во втором вернет все записи.
Это опечатка, или я чего-то не понимаю?
В первом случае вернет запись с id=1, во втором вернет все записи.
А как же float? А отрицательные значения?
Такие данные не используются. По этому тут нет такого. Но добавить не сложно
Ну это просто несерьёзный подход. Вы публикуете статью «Приведение к типам», а в результате демонстрируете довольно сомнительное приведение к int и ничего более.
Я хотел ознакомить людей с возможной проблемой и решением, которое я применил. Я же не писал расширение для каталога Yii extensions, а показал часть кода нашего проекта.
Тем не менее, люди хотят ознакомиться с более качественным подходом. Я не использую Yii, но как раз в данный момент работаю над аналогичной задачей в более широком спектре использования. От вашей публикации я ожидал как минимум демонстрации нескольких типов данных и более-менее готового решения, которое чему-то учит. Всё-таки данный ресурс — не личный дневник с заметками на полях.
Не говоря уже о том, что ваш код угробит значение '123456789876546548786546875468'.
Не говоря уже о том, что ваш код угробит значение '123456789876546548786546875468'.
if (preg_match("/^[\d]+$/", $prop)) $prop = (int)$prop;Замечательно. А теперь скажите, пожалуйста, что мы получим, если исходным значением будет строка '0001234'?
Т.е. получается, что нельзя использовать строковые поля, в которых содержатся только цифры?
У нас не возникает ситуаций, когда число нужно передать в виде строки, по этому данное решение полностью покрыло потребности проекта
Каюсь, с первого раза это не увидел, но всё же надо такие моменты учитывать тем, кто захочет перенять подобный способ
Да, согласен с вами, что метод требует доработок.
Была, кстати, пробема с одним фреймворком из-за того, что он самостоятельно пытался принимать решение о типе данных основываясь на содержимом. Там была функция ctype_digit вместо регулярки, но суть та же. Как вы написали в статье, для MySQL особой разницы нет (если включен соответствующий режим), но ведущие нули обрезались, что неправильно
Использовал просто функцию с сигнатурой вроде
У нас не возникает ситуаций, когда число нужно передать в виде строки
Очень редкий случай, по-моему, когда в требованиях написано что-то вроде «логин не может быть 123».
P.S. Использование тут регулярок — из пушки по воробmям, имхо. is_numeric($prop) и/или strval(intval($prop)) === $prop
P.P.S. DRY — даже если использовать — не повторяйтесь
И зачем функция public?
public function getParam($name, $defaultValue=null, $type = 'string')
У нас не возникает ситуаций, когда число нужно передать в виде строки
Очень редкий случай, по-моему, когда в требованиях написано что-то вроде «логин не может быть 123».
P.S. Использование тут регулярок — из пушки по воробmям, имхо. is_numeric($prop) и/или strval(intval($prop)) === $prop
P.P.S. DRY — даже если использовать — не повторяйтесь
public function parseData(&$data)
{
if (is_array($data)) {
foreach ($data as &$prop) {
$this->parseData($prop);
} else {
if (preg_match("/^[\d]+$/", $data)) $data = (int)$data;
}
}
И зачем функция public?
Sign up to leave a comment.
Приведение к типам в Yii::app()->request