Приветы, у8важаемые гуру ПХП 

Довольно много приходится переменных из GET/POST доставать. Каждый раз приходится писать в форме 



нельзя ли как нибудь попроще такое написать? Моз
хет есть функция, кторая вместе с isset делает и присваивание? Самое противное, что самому такую не написать...
хотелось бы чтото вроде:



"своя" получилась бы:


Что весьма некрасиво..

Что-то не совсем понятно. Обычно пишут:

capitan, 
ты щас написал более усложненный вариант :-P

  
capitan, это то же самое, только используется условный оператор

Например выражение  присвоит переменной max большее из чисел a и b 

P.S. извиняюсь, что влез не в свой раздел

Это сообщение отредактировал(а) ivashkanet - 3.5.2007, 13:33

Вообще задача в идеале не решаемая т.к. если переменная не переданна, то как мы будем передавать ее функции, но есть хитрость, а именно сокрытие ошибок...

sergejzr, а что-то типа ?
Все, не буду мешать.

Можно еще реализовать, как ivashkanet говорит, но это придеться указывать какой именно массив  

Как огранниченный выход из ситуации, можно юзать $_REQUEST в функции...

Не очень хочется.. Или это нормальный приём?



isset - то работает..


Дело в том, что хочется не только GET/POST, а универсальный вариант..

sergejzr, 


Ну в данном случае вполне нормальный мне кажеться, ведь мы пропускаем переменную для проерки, а не в свободный полет пускаем...
К тому же я не верно выразил мысль, это не ошибка, а нотейс т.е. интрипритатор дает знать нам, что скорее всего мы что то не учли и в 99% случаев он прав, этот случай мне кажеться 1% когда мы правы...



Ну, если юзать isset, до передачи значения функции, то какой толк тогда от функции? 

это не хитрость - это вред карме 

не пойму чем одна функция некрасивее другой.
для индекса массива второй вариант вполне даже
а для самостоятельной переменной обычного isset должно хватить

Это сообщение отредактировал(а) Glip - 3.5.2007, 14:50

Glip, 
В данном случае, это именно тот момент, ради которого существует данный элимент сокрытие ошибок... имхо

Я ведь не предлагаю его использовать ещестрочно и прекрасно понимаю, что злоупотреблять этим элиментом нельзя...

Glip, а так:  ?

Glip, 
И вообще, мне что-то подсказывает, что ты просто не вник в суть... попробуй сам написать функцию ;)
Я тоже сначала не понял, в чем проблематаки 


ivashkanet, 
  
не выдержал 

ivashkanet,  а в первом варианте вообще смысла не вижу 

@ - отключение ошибок. Быстро и удобно.

Это сообщение отредактировал(а) GZep - 3.5.2007, 15:00

А вот и наглядный пример, того как нельзя использовать @
  

BuShaRt, а почему же нельзя?

GZep, 
Все ошибки и нотейсы должны выводиться пре откладке 
и
полностью скрываться на уровне конфигурации PHP пре использование движка.

В том, случае, который привел я, интрипритатор выводит нотейс, т.к. ему невдамек, что переменная передаеться, для обработки.
В твоем случае идет не чем не обоснованное сокрытие вывода ошибок.

Если копать глубже, то конструкция

и есть решение, которое позволяет писать валидный код, не прибегая к твоему примеру


т.е. по суте ты предлагаешь вернуться к старым, непродуманным методам кодирования, когда есть методы более современные и поддержанные видущими программистами...

Если хочется так, то не пойму в чем проблема:


Или я что-то упустил? Никак не могу понять в чем проблема написания данной функции?

Лично я часто завожу в начале скрипта массив дефолтных ожидаемых значений, пробегаю по его индексам и смотрю - если такой индекс пришел из формы, заменяю на значение оттуда (заодно проверив на допустимость), если нет - оставляю дефолтное. А потом в нужном месте просто подставляю соответствующий элемент этого массива...

а лично я вижу в этом подходе только преимущества в сравнении с "раздельным хранением":
1) ортодоксальный алгоритм загрузки и перекрытия дефолтных значений(не "сколько переменных - столько и вызовов функций", а один foreach)
2) данные, которые могут прийти из форм, собраны в одной переменной - массиве: так что внешние связи отделены от внутренних. Удобно и компактно для изменения.
3) (скорее, камень в огород "раздельнохранимости") очень часто надо инициировать переменные, хранящие значения из форм, дефолтными значениями на случай отсутсвия данных.
При раздельном хранении будет дополнительно ещё куча строк с присвоением. В случае массива - одна строка инициализации массива 

никакой ошибки isset не генерирует!

и тут тоже никакой ошибки не генерируется!

не в этом случае. Тут просто проверяем существование переменной и все.

if (@...) - абсолютно не старый способ и его как раз ведущие программисты и используют. А ваш isset будет пропускать все значения кроме null, поэтому его надо использывать в связке с empty => слишком громоздкая конструкция - ниодин "ведущий" программист так писАть не будет.

GZep, 
я понял в чем проблема, ты просто не знаешь значение оператора @.
Это вовсе не сокращенная форма isset, а сокрытие ошибок...

Удостоверься



mishaSL, 
А что в данном случае означает оператор & ?

Передача аргумента в функцию по ссылке.

mishaSL, 
Что то знакомое, но вспомнить не могу, можно  чуть поподробние?

Уважаемые, конструкция: $a= isset($_GET["a"])?$_GET["a"]:false;
неправильная, хотя бы потому, что если вы дальше будете использовать конструкцию: if(!$a) {если нету} то эта конструкция будет выполняться также и если а установлена и равна 0. ;)

Для упрощения работы с формамы я использую (если количество переменных динамическое значение) масивы переменных.
то есть 

Очень удобно потом проверять ;)
если устанолвена A, то проверяем их количество, если не совпало - форма пришла левая.
Если совпало, проверили на SQL баги, и удобно делать проверки с помощью циклов.

надеюсь вам помог )

Добавлено через 3 минуты и 5 секунд
BuShaRt, это значит что передается не значение переменной, а ее ссылка.
то есть:

Выше есть подобный вариант, но там переменная передается не по ссылки, а клонируется, поэтому возникают ошибки.

Добавлено через 2 минуты и 16 секунд
ЗЫ: Оказалось парня успел поправить уже mishaSL )

Это сообщение отредактировал(а) CyClon - 4.5.2007, 14:32

Kallisto, 
Очень правильная конструкция, просто ее использоваь надо с умом, а не пихать куда попало 
По большей часте ею проверяються GET-запросы, причем не с форм...

Вот пример:

Т.е. мы можем далее смело использовать переменные $action и $page


*Смело, если конечно не передаем эти данные в уязвимые места кода... но это другая история...


Всем
Спасибо, что открыли мне оператор &.

Добавлено через 6 минут и 24 секунды
Выдержка из стать: Осторожно, данные!
Автор: Кузьма Феськов

Первое правило безопасности
Первое, что вы должны научиться делать, это принимать данные из правильных источников.
Основные источники данных в PHP – это суперглобальные массивы, в частности $_GET и
$_POST. Приучайте себя брать данные именно из этих массивов. Также не лишним будет
отметить, и тот факт, что параметр php.ini register_globbals должен быть off.
Немного поясню последнее замечание о register_globbals. Ни раз мною замечалось – до сих пор
многие программисты не понимаю почему этот параметр важно устанавливать в значение off.
Многим кажется удобным, что переменные, переданные в скрипт методом POST или GET сразу
появляются в пространстве скрипта и готовы к использованию. Однако, это удобство крайне
обманчиво. Во-первых, если вы используете в своем скрипте какую-то переменную и заранее не
позаботились об инициализации ее значения, то, дописав в URL ее название, я легко могу
переопределить ее значение на нужное мне, в результате ваш скрипт этого даже не заметит. Во-
вторых, вы никогда не будете знать точно, каким именно образом вам передана та или иная
переменная. Есть и другие менее значимые факторы. Исходя из всех этих замечаний, легко
понять, что опасность подобного подхода весьма велика и он прямо ставит под угрозу написанные
вами скрипты.
PHP Inside'18 >> Идеи >> Осторожно, данные!
После небольшого отступления, давайте перейдем к практике. Итак, к нам поступила (или не
поступила) переменная методом GET:

О переменной мы заранее знаем, что она придет методом GET, будет содержать целое число.
Первым делом, мы присваиваем значение локальной переменной. Естественно, многие сделали
это следующим способом:

Однако, что произойдет в том случае, если переменная не пришла (возможно кто-то пытался
испытать ваш скрипт на прочность и стер ее из URL)? Правильно – вы получите сообщение об
ошибке (NOTICE мы договорились считать ошибкой). Чтобы этого не произошло, необходимо
изменить наш код следующим образом:

Для простоты кода и удобства, я применил в данном случае так называемую короткую нотацию
оператора if. В обычном виде скрипт выглядел бы так:

Но, согласитесь, эта запись слишком громоздка.
Давайте вернемся к нашему коду. Мы с вами использовали команду isset, которая проверяет
наличие переменной или индекса в массиве, и возвращает false если такого элемента нет, и true,
если он есть. Что позволяет нам избежать обращения к несуществующему элементу. Поскольку
мы заранее знаем, что эта переменная может содержать только целые числа, то, не анализируя ее
содержимое, мы приводим его к целому числу. В данном случае мы применили короткую команду
(int), которая эквивалентна intval(). Даже если вам передадут в этой переменной вместо числа
строку, данная команда приведет ее к числу 0, что является целым числом и вполне удовлетворяет
нашему требованию.
Это, безусловно, очень простой пример, но он способен показать все хитросплетения и повороты,
которые подстерегают нас на пути написания скрипта.
Итак, первое правило: Всегда берите значения там, откуда они должны придти в скрипт.
Всегда проверяйте переменные и индексы массивов на существование перед их
использованием. Всегда инициализируйте значения переменных перед их использованием.

BuShaRt, 

Вы не правы. Я прекрасно знаю, что делает @ и & и так далее... Прочитайте труд Дмитри Котерова "PHP5 В подлиннике" и убедитесь сами, что в подобных случаях использование @ куда более грамотно чем isset/empty. С г-ном Д. Котеровым не поспоришь...  

А не проще-ли, для сокрытия ошибок от конечного пользователя просто отключить их отображение в интерпретаторе? )

GZep, 
Еще как поспорю, не раз на форуме поднимался вопрос о некомпетентности авторов книг. 

Интервью с Леонидом Лукиным

Вот выдержка из ответа




WolfON, 
Ну, я об этом упомянул выше, но по суте и на этапе откладки нужно писать так, чтоб ошибок не было ;)

BuShaRt, вот скажите:
мы проверяем, передаются ли данные из формы или клиент ничего не передает.

Какие тут могут быть ошибки???? Причем тут ошибки? Может типа такого: "не могу определить, ты нажал кнопку под формой ввода данных или нет? не пойму никак?" или вот такие ошибки: "неизвесная функция 'isset'! ". Причем тут ошибки?

Выражения:

и

эквивалентны. Более того ниодно из них не генерирует ошибок.

GZep, 
@ - не может генерировать ошибок, как и system('rar e arhiv >nul'); не выводит сообщений 
Но ведь >nul не глушит вывод в бинарнике, а лишь переадресовывает вывод в пустоту 

так нам это и нужно.

З.Ы. вообщето может.  

Какие ошибки? 
Ошибка в том, что

Передает, null в if, а if работает только с true/false т.е. интрепритатор упрощая жизнь программисту принимает null, как false и генерирует нотейс, уповещяющий о том, что так делать нельзя!
Но вы оператором @ просто глушите вывод этого нотейса и интрипритатор молча делат за вас работу по изменению null на false...

Добавлено через 1 минуту и 8 секунд

Вот, если вы приведете пример, как @ выводит ошибку, я удалю все свои посты, извенюсь и дам вам плюсик 

BuShaRt, 
GZep, Модератор: вы далеко ушли от темы, если хотите обсудить правильность того или иного способа проверки входных данных для этого можно создать отдельную тему.

Добавлено через 3 минуты и 16 секунд
CyClon, по всей видимости тебе показалось   оператор & был с самого начала  

А почему бы не дать делать PHP за вас грязную работу? Тем более, что код от этого становится более красивым. Согласитесь, что isset + !empty - слишком длинно...

Yeah!
Вот, пожалуйста:

  

Это сообщение отредактировал(а) GZep - 4.5.2007, 17:30

mishaSL, 
Ну почему же? Был предложен самый коротки вариант. Что самый короткий кажеться нет сомнений, вот мы думает, а надо ли его использовать?
все по теме ... или нет? 

mishaSL, ничего, ибо теперь:

сообщений станет меньше...  

GZep, 
Причем тут @, когда ошибка выводиться из-за несущестование константы к которой @ не как не относиться? 

Вот, и не одной ошибки 

BuShaRt, я уже подправил код, посмотрите еще раз.

Дубль три?

Добавлено через 2 минуты и 58 секунд
Более того, 



Собачка в действие  Вывод ошибок = 0

включи в 5-ой версии, скорее всего 4-я версия не умеет принимать 2-ой параметр. Если нету 5-ой, то попробуй еще раз в 4-ой вот это:

GZep, 
Вы только, что доказали свою неправоту )))))

Интрипритатор отметил ошибку, но не вывел ее т.к. @ ее скарыла... После чего вы ее извлекли вручную ))

Значит ошибка есть! Какие тут еще могут быть споры?



  
И если вы так принципиально хотите, чтоб я удалили посты т.к. вы доказали, что вывод ошибок может быть и пре указанному @, то я вас огорчю, вы отметили, что @ может вывести ошику, а я свою очередь попросил пример, того как @ выведет ошибку...
В пример вы привели, то как ошибка возникает из-за необъявленной переменой, а вовсе не из-за @.

Нет, не вывел потому что я взял на себя обязанность обрабатывать ошибки и не согласился с тем, что @ должен блокировать ошибки.

ха-ха, ну ты даешь! Браво! Кроме того необявленную переменную я взял для примера, чтобы показать, что можно добиться того, чтобы @ не скрывал ошибку. И я это сделал.

Ну, если тебе так хочется, чтобы @ вызвал ошибку, то пожалуйста:

Правильно, поэтому isset тут лишний абсолютно .

ну, это завиит от конкретной ситуации.

GZep, не зависит. В ситуациях, когда по смыслу нужен empty, его и достаточно (он сам по себе не дает нотайса на несуществующую переменную), если нужно проверить существование переменной независимо от значения, хватит одного isset-а. А if (isset($a) && !empty($a)) полностью эквивалентна if (!empty($a)) - разве не так?

GZep, 
Спор зашел в тупик и двоем мы точно не найдем ответа, будем ждать людей более опытных...

SelenIT, дошло  

BuShaRt, короче, ладно.  согласен с закрытием этого спора. Думаю, что мы раскрыли эту проблему так как никто ее еще не раскрывал...лови медаль в репу!  

GZep, 
  
Позитивный ответ, радует... и спасибо за урок по ручному котролю ошибок ;)

у меня сегодня получилось

это конечно далеко от

но зато симпатичнее, чем

да и с null/0 все знаем, как PHP расправляется, но может, кому-нибудь понравится 
если ноль не ждем)

Это сообщение отредактировал(а) Alx - 18.12.2007, 01:39

Alx, если ты настаиваешь на:

, то очень зря
почитай это http://phpclub.ru/talk/showthread.php?s=&a...mp;pagenumber=1
я честно говоря пёрся по этому восьмистраничному эпосу,
но фанатичный модератор верно указывает на следующий факт:

животное @ - ни в коей мере не должна быть частью исполнительного кода,
это всего лишь средство отладки для программиста, и по завершению создания кода, его скрипты по определению не должны генерировать ошибок

для меня хватает уже этого

если тебе недостаточно, многие начинают уверять, де почему нельзя использовать, если она даёт нужный результат и т.п....

низя!
генерация ошибки и её погашение по определению будет жрать больше ресурсов, чем спокойный ход программы
один из товарищей на тамошнем форуме произвёл проверку на время, как оказалось @ на порядок увеличивает время выполнения

ну а если хочется кокретно поспорить, ссылка на форум дана

Проще написать можно так:


Это если строго соблюсти условие.
Проще будет $a =  @$_REQUEST['a'];
А дальше смотреть не false а null.

Не проще ли так?



Это сообщение отредактировал(а) Anarki - 18.12.2007, 16:28

А так не пойдёт?


А потом вызывать:

Так шаблоны в среде разработки вроде никто не отменял   

я использую @.
и не вижу в этом ничего плохого. например,так:



или так::



считаю, что в данных случаях это оправдано.

так почему бы и не писать



Добавлено через 48 секунд
тем более что конструкция @... or... вполне официальная конструкция языка

да ну на фиг! пошлите меня туда, где это написано

ага, сам себе помощь скрываешь... а так больше ничего плохого ;)