Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Получаю данные о профиле. Некоторые поля необходимы хранить в виде json (в БД). Во view не могу получить отдельные данные этого json ответа. Как быть?
Немного растолкую на всякий...
Получаю данные о профиле по стандарту: User::where(...). В БД профиля хранится несколько строк, в которых сохраняется json, например "{"f_users":"Имя","i_users":"Фамилия","o_users":"Отчество"}".
Все данные можно просто выводить через $profile->login_users и т.п. А вот, например, когда получаю json строку, то выводится только JSON код. Как обратиться, например, к f_users?
Не в сети
Где ты получаешь json строку?
в php - json_decode
в javascript - JSON.parse
эти функции преобразуют json строку в объект.
после этой процедуры, ты сможешь обращаться к свойствам, например:
$json_string = '{"foo":"bar"}';
$json_object = json_decode($json_string);
var_dump($json_object->foo); // string(3) "bar"
Изменено covobo (26.07.2017 17:11:29)
Не в сети
в php - json_decode
Только такой вариант для преоброзования json в объект?
И ещё вопрос:
Сделал функционал выхода пользователя из аккаунта:
public function getLogout(){
if(Auth::logout()){
return redirect()->route('home')->with('successMessages', 'Вы успешно вышли из аккаунта!');
}else{
return redirect()->route('home')->with('errorMessages', 'Ошибка при выхода из аккаунта!');
}
}
Но выполняется почему то код в else: return redirect()->route('home')->with('errorMessages', 'Ошибка при выхода из аккаунта!');. При этом из аккаунта выходит. В чём может быть дело?
Изменено dima9595 (27.07.2017 07:35:20)
Не в сети
Auth::logout() ничего не возвращает, void. А ничего - false
Не в сети
Как я понял, у тебя столбец в JSON и ты хочешь его автоматически преобразовать в массив. В таком случае используй преобразотватели в JSON, которые созданы как раз для таких случаев:
https://laravel.ru/docs/v5/eloquent-mut … бразование
Изменено AlexeyMezenin (27.07.2017 09:54:53)
Не в сети
Как я понял, у тебя столбец в JSON и ты хочешь его автоматически преобразовать в массив. В таком случае используй преобразотватели в JSON, которые созданы как раз для таких случаев:
ВО!) То что надо, спасибо!
Не в сети
Auth::logout() ничего не возвращает, void. А ничего - false
Странно...Раньше так делал и работало...
Не в сети
Странно...Раньше так делал и работало...
Я бы сказал, что это вообще порочная практика из Си - возвращать 0 или 1, тру или фелс. По идее если что-то случилось внутри Auth::logout() (или чего угодно еще), то оно должно кинуть Exception наружу, а ты его перехватить. За конкретно этот метод не ручаюсь, конечно.
Не в сети
Я бы сказал, что это вообще порочная практика из Си - возвращать 0 или 1, тру или фелс.
Кроме методов, которые предназначены для возврата true/false - is/are/arent/have/has... isValid/hasName/etc..
Не в сети
Я бы сказал, что это вообще порочная практика из Си - возвращать 0 или 1, тру или фелс. По идее если что-то случилось внутри Auth::logout() (или чего угодно еще), то оно должно кинуть Exception наружу, а ты его перехватить. За конкретно этот метод не ручаюсь, конечно.
В Си это как раз объяснимо: в языке исключений вообще не было (даже в С++ они не во всех случаях работают), и, кроме того, программирование без исключений считается более надёжным. К тому же, в компилируемых языках исключения дороги в плане быстродействия (в интерпретируемых - не обязательно так), поэтому приходится выбирать - если функция штатно может выбросить исключение, то вместо этого она возвращает код ошибки.
Самое интересное, это когда в коде попеременно используются то исключения, то коды возврата... Или как в самом PHP - есть исключения, есть коды возврата, а есть ошибки, которые выводятся в браузер! Хорошо, что чем дальше, тем их остаётся меньше.
Не в сети
кроме того, программирование без исключений считается более надёжным
сомнительно.
о чем речь?
Не в сети
о чем речь?
Во встроенных языках и в высоконадёжных системах (космос, медицина, банки и т.д.) считается, что исключения использовать нельзя, так как они неявно меняют поток выполнения и в любой момент могут быть выброшены в любой функции (в противоположность использования кодов возврата, которые явно описаны в функции).
Также они вызывают и другие вопросы, например, по части освобождения ресурсов: без исключений у тебя один control flow и вероятность забыть освободить ресурс меньше. Или: если исключение в конструкторе объекта - вызывать ли деструктор? Или: корректно ли использовать return в finally? Или: в каком порядке вызывать catch (как if или как switch/case), и вызывать ли несколько catch, если они совпадают по классу? И так далее.
A contrasting view on the safety of exception handling was given by C.A.R Hoare in 1980, describing the Ada programming language as having "...a plethora of features and notational conventions, many of them unnecessary and some of them, like exception handling, even dangerous. [...] Do not allow this language in its present state to be used in applications where reliability is critical[...]. The next rocket to go astray as a result of a programming language error may not be an exploratory space rocket on a harmless trip to Venus: It may be a nuclear warhead exploding over one of our own cities."
Citing multiple prior studies by others (1999–2004) and their own results, Weimer and Necula wrote that a significant problem with exceptions is that they "create hidden control-flow paths that are difficult for programmers to reason about".
Go was initially released with exception handling explicitly omitted, with the developers arguing that it obfuscated control flow. Later, the exception-like panic/recover mechanism was added to the language, which the Go authors advise using only for unrecoverable errors that should halt the entire process.
One case of early criticism against Exception handling was dealing with resource leaks or state inconsistence, such as escaping a section locked by a mutex, or one temporarily holding a file open. This have largely been solved by RAII and the dispose pattern, which had to be specifically invented to solve the issue, but have proven to be useful in other contexts.
https://en.wikipedia.org/wiki/Exception … #Criticism
В С++ нет finally:
Why doesn't C++ provide a "finally" construct?
Because C++ supports an alternative that is almost always better: The "resource acquisition is initialization" technique (TC++PL3 section 14.4).
http://www.stroustrup.com/bs_faq2.html#finally
В самом PHP до 5.5 не было finally по тем же причинам:
We've had long discussions and came to the only conclusion that we don't need that, for more search the mailing list archieves.
https://bugs.php.net/bug.php?id=32100
Я это к тому, что исключения - концепция сложная, со множеством решений, которые могут быть приняты по-разному, в отличии от возвращаемых значений у функции, где всё очевидно.
Не в сети
Я это к тому, что исключения - концепция сложная, со множеством решений, которые могут быть приняты по-разному, в отличии от возвращаемых значений у функции, где всё очевидно.
Спасибо за ответ.
Все же, все зависит от контекста, могу допустить, что существуют контексты (проблемы/задачи..), в которых использование исключений - не очень безопасный подход, но, говорить об этом обобщенно - мне кажется слишком громко.
Со своей стороны могу сказать, что, поняв всю мощь исключений, я стал их использовать не только в случае:
$res = fopen('tmp_buffer_path');
if (!$res) {
throw new \RuntimeException(error_get_last());
}
Но и при описании бизнес логики.
Не в сети
в которых использование исключений - не очень безопасный подход, но, говорить об этом обобщенно - мне кажется слишком громко.
В целом, согласен, хотя некоторые знакомые при мне высказывались именно так.
Я лично люблю исключения - они делают код чище, устраняют многие проверки, с ними обработка ошибок видна с первого взгляда. Да, есть сложности, как и везде в программировании; ими можно злоупотреблять, но пользы больше. Космос, медицина и так далее - это совершенно отдельная область со своими правилами игры и ЯП.
Не в сети
Страницы 1