Согласен, следовало более чётко оговорить, что речь про использование на фронтенде.
Просто руководства, типа процитированной мной в другом комментарии документации по PDO, не разделяют эти понятия.
Это интересный вопрос. Испытываю очень большой соблазн переадресовать его авторам руководств по prepared statements, упорно толкающим этот лозунг.
Увы, сам я тестов не делал, но есть подозрение, что это, все-таки, работает. К примеру, такая технология, как HandlerSocket как супер-скоростной способ доступа к БД позиционируется именно благодаря «изыманию» SQL из процесса. То есть, какие-то накладные расходы на парсинг и построение плана запроса всё-таки есть.
Если бы идея пошла, я бы обязательно сделал замеры производительности. Но поскольку пользоваться таким вариантом всё равно нельзя, то и тесты я счёл бесполезными.
1) Пользователь тут вообще не при чём. Задача класса по работе с БД — работать с БД. А не с пользователем. Хотим проверить ввод на валидность — ради бога, ДО любых манипуляций с SQL.
Собственно, «ошибки» выводимые пользователю — это не ошибки с точки зрения программы, а нормальная работа в штатном режиме. Я же говорил об ошибках, возвращаемых сервером БД, при попытке выполнить запрос.
2) Вы путаете саму ошибку и сообщение о ней. Про сообщения об ошибках речи не было. Я говорил о самой ошибке. Которая существует независимо от способа информирования о ней.
Как раз в уроки природоведения, мне кажется — последнее время, когда будешь интересоваться пределами температур. А дальше уже появляются другие интересы.
> Здесь отображено значение второго счётчика максимальной высоты. Путь в поезде из Симферополя в Минск. я даже и не заметил когда мы так высоко забрались.
Понять бы ещё, для чего нужна эта цифра, кроме как написать о ней на Хабр.
Я привёл в статье два примера ошибок, исправленных совсем недавно.
Это означает, во-первых, что столь серьёзные баги всплывают до сих пор, а во-вторых — они мешали массовому использованию (а значит — тестированию) экстеншена. Что означает довольно большую вероятность появления новых багов в будущем.
Пользователи имеют склонность открывать больше одной страницы сайта.
Как минимум, нужно иметь пул этих «секретов».
Но я сейчас не о недостатках конкретно этого метода, а о недостатках сайтов типа хабрахабр. На которых можно увидеть миллион полезных советов… которые никто из советчиков никогда не применял на практике. А все только лишь переписывают друг у друга.
Да, как раз об этом пишу.
Я почему-то полагал, что в описание паттерна входит и обработка ошибок. А сейчас посмотрел — там просто про редирект.
Так что мой комментарий оказался лишним, стоило просто плюсануть самый первый.
Напишу тогда про сессии.
С ними тоже не всё слава богу: если удалять данные поста сразу после редиректа, то перезагрузка страницы позволит-таки юзеру очистить форму от введённых в нее данных (понятно, что он будет сам дурак, но ведь юзабилити — это и есть забота о как раз таких вот пользователях...).
А если удалять после успешной обработки, то надо предусматривать наличие в сессии зоопарка из заполненных форм — пользователи часто заполняют по две сразу.
есть более простое: ru.wikipedia.org/wiki/Post/Redirect/Get
Редирект надо делать только после успешной обработки формы. А при ошибках это делать не обязательно.
И — да, это тянет на вопрос, а совсем не на статью.
Об этом и речь.
При этом из аргументов у них только «старая» и «две другие есть».
Ну так для замены «старого» курла даже больше новомодных кунштюков есть — от fopen-wrappers до php_http. Но курл никто из языка не выпиливает.
Так что если у вас есть ссылка на вменяемое объяснение причин удаления — я был бы благодарен на самом деле. Поскольку, как я уже говорил, я не сторонник этого расширения как такового — я сторонник осмысленных и аргументированных действий вообще.
Вы не могли бы привести пример какого-нибудь места, которое может быть неясно?
Я старался расписать максимально понятно, но мог и не преуспеть. Но всё поправимо, и я буду рад внести правки, делающие статью более понятной.
Проблема коммуникации гик-новичок действительно существует — я даже отметил её во вступлении.
Беда в том, что когда новички пишут для новичков — выходит ещё хуже.
В общем, если можете указать на конкретные неясности в статья — я был бы благодарен
Просто руководства, типа процитированной мной в другом комментарии документации по PDO, не разделяют эти понятия.
Увы, сам я тестов не делал, но есть подозрение, что это, все-таки, работает. К примеру, такая технология, как HandlerSocket как супер-скоростной способ доступа к БД позиционируется именно благодаря «изыманию» SQL из процесса. То есть, какие-то накладные расходы на парсинг и построение плана запроса всё-таки есть.
Если бы идея пошла, я бы обязательно сделал замеры производительности. Но поскольку пользоваться таким вариантом всё равно нельзя, то и тесты я счёл бесполезными.
1) Пользователь тут вообще не при чём. Задача класса по работе с БД — работать с БД. А не с пользователем. Хотим проверить ввод на валидность — ради бога, ДО любых манипуляций с SQL.
Собственно, «ошибки» выводимые пользователю — это не ошибки с точки зрения программы, а нормальная работа в штатном режиме. Я же говорил об ошибках, возвращаемых сервером БД, при попытке выполнить запрос.
2) Вы путаете саму ошибку и сообщение о ней. Про сообщения об ошибках речи не было. Я говорил о самой ошибке. Которая существует независимо от способа информирования о ней.
Но вообще я могу понять восторг по поводу часов со 100500 функций. В 8 классе пацаны бы обзавидовались.
Впрочем, вопрос был риторический.
Понять бы ещё, для чего нужна эта цифра, кроме как написать о ней на Хабр.
Это означает, во-первых, что столь серьёзные баги всплывают до сих пор, а во-вторых — они мешали массовому использованию (а значит — тестированию) экстеншена. Что означает довольно большую вероятность появления новых багов в будущем.
Как минимум, нужно иметь пул этих «секретов».
Но я сейчас не о недостатках конкретно этого метода, а о недостатках сайтов типа хабрахабр. На которых можно увидеть миллион полезных советов… которые никто из советчиков никогда не применял на практике. А все только лишь переписывают друг у друга.
Я почему-то полагал, что в описание паттерна входит и обработка ошибок. А сейчас посмотрел — там просто про редирект.
Так что мой комментарий оказался лишним, стоило просто плюсануть самый первый.
Напишу тогда про сессии.
С ними тоже не всё слава богу: если удалять данные поста сразу после редиректа, то перезагрузка страницы позволит-таки юзеру очистить форму от введённых в нее данных (понятно, что он будет сам дурак, но ведь юзабилити — это и есть забота о как раз таких вот пользователях...).
А если удалять после успешной обработки, то надо предусматривать наличие в сессии зоопарка из заполненных форм — пользователи часто заполняют по две сразу.
Редирект надо делать только после успешной обработки формы. А при ошибках это делать не обязательно.
И — да, это тянет на вопрос, а совсем не на статью.
При этом из аргументов у них только «старая» и «две другие есть».
Ну так для замены «старого» курла даже больше новомодных кунштюков есть — от fopen-wrappers до php_http. Но курл никто из языка не выпиливает.
Так что если у вас есть ссылка на вменяемое объяснение причин удаления — я был бы благодарен на самом деле. Поскольку, как я уже говорил, я не сторонник этого расширения как такового — я сторонник осмысленных и аргументированных действий вообще.
Я старался расписать максимально понятно, но мог и не преуспеть. Но всё поправимо, и я буду рад внести правки, делающие статью более понятной.
Проблема коммуникации гик-новичок действительно существует — я даже отметил её во вступлении.
Беда в том, что когда новички пишут для новичков — выходит ещё хуже.
В общем, если можете указать на конкретные неясности в статья — я был бы благодарен