Pull to refresh

Comments 37

UFO just landed and posted this here
С одной стороны — хорошо, с другой — накладывает излишние ограничения (вроде невозможности переопределить время выставления кук). На мой взгляд, лучше использовать собственные врапперы вроде setcookie($name, $value), getcookie($name), не менее удобные, но дающие возможность указывать значения отличные от дефолтовых.
А помоему можно допилить этот класс, сделав _setCookie() доступной вне класса. Тогда и дефолтное expire можно изменить, и path.
И получится функция set_cookie:)
Да :)
Нужно в нее еще добавить сохранение в массив storage[] и будет действительно setcookie с без стандартного потери функционала.
Можно добавить публичный метод:
simpleSetCooke($name, $value, $expire=0x7FFFFFFF)

Остальные параметры (domain, secure, httponly) практически никогда не используются и идут в лес.

Потом можно допилить эту функцию, что бы третьим аргументом она могла принимать строку и прогонять её через strtotime(). Например:

$COOKIE->simpleSetCooke('foo', 'bar', '+2 week'); // разве не клёво?

В любом случае, топикстартер создал фундамент, а построить на нём можно очень много.

P.S. Переопределять глобальные переменные, это конечно же очень плохо.
Ну автор как раз хотел избавиться от функций (методов), а тема оберток стандартных функций (глобальных переменных) это уже другая тема. А так да, действительно классно, но слишком длинно ($COOKIE->simpleSetCookie...), лучше уж Cookie::set(...) какой-то.
У меня без всяких SPL и ArrayAccess die(print_r($_COOKIE)); выводит массив кук. Я что-то делаю не так?
Простите. Вы имеете ввиду установку кук. Я подумал что получение.
Вообще ArrayAccess очень удобная порой штука. Я на ней делал поиск переводов в шаблонах. Просто переопределяя обычный массив переводов объектом с ArrayAccess
Сто лет не работал с $_COOKIE напрямую, всё через класс, свой или от CodeIgniter.
trigger_error('Cookie value was not set', E_USER_WARNING); может лучше Exception кидать?
Да ладно. Всегда ли приложение не может работать без куки?
Exception нужно еще отлавливать, по умолчанию скрипт просто завершит работу при возникновении исключения. Обычный warning просто будет проигнорирован.
что мешает добавить try{} catch(e)?
Все еще игнорируете варнинги? Тогда мы идем к вам!
А я наоборот предпочитаю обертки, даже для $_SESSION или там $_POST.
Боюсь, что unset реализован неправильно — следуя этому интерфейсу, клиент будет ожидать, что кука удалится на клиенте после вызова unset.
Да, и кстати, — переписывать супеглобальные массивы — это плохо :)
да, вы правы, unset стоит дополнить.
trigger_error('Cookie value was not set', E_USER_WARNING);
не делайте так… кидайте исключение. их придумали гораздо раньше SPL
Идея на пятёрку. Велосипед — это здорово.
Вообще, ИМХО велосипед = новый код, которого раньше не было, который реализует существующую идею или её часть.
А как задать домен, время жизни и другие параметры?
Забавно. Вас не смущает, что работа с cookies на php потому и происходит через setcookie, что иначе выплывает ряд проблем? Идея интересна в реализации, но абсолютно бесполезна
Каких? Расскажите, если не затруднит.
Во-первых, самая очевидная проблема — заголовки могут быть уже отправлены. Сегодня это не так актуально, но сама функция setcookie добавляет наглядности.
Во-вторых, наличие отдельно read-only массива и функции установки символизирует саму схему работы с ними. Только после отправки заголовка и обновления страницы мы можем удостовериться, что cookie установлен. У вас же все в перемешку
Это то, что сходу в голову пришло. Может еще что-то придумаю (не считая сложности реализации, неустойчивости и т.д.: не будем консерваторами и вообще унылыми личностями, эти проблемы несущественны)
В куках, в отличии от сессии, не только ключ значение, а еще и ряд дополнительных параметров хранения.
ООПничать так ООПничать — саму куку нужно сделать объектом. Обязательный параметр в конструкторе -значение куки, необязательные — домен, время и т. д. Плюс метод __toString(), возвращающий строковое значение. А методы ArrayAccess возвращают/принимают объект. Как-то так :)
Решение абсолютно бесполезно, хотя бы по следующим причинам:
1. Любой опытный программист знает что $_COOKIE['name'] = 'val' никуда ничего не сохраняет. И подсознательно это использовать не будет.
2. В любом месте программы можно допустить ошибку if ($_COOKIE['name'] = 'myval') и весь механизм летит к черту. Это как вариант). Проблема глобальных переменных.
3. Куки ставятся на заранее заданное кол-во времени и управлять этим никак нельзя, возвращаемся к setckookie. А если мне надо их поставить на год? А если на сессию?
Навскидку что пришло в голову, возможно есть еще нюансы.

Рискну предложить свою обертку которую я использую. Подрихтовал немного и выложил на гитхаб: github.com/behigh/Cookie
2. Во избежание всегда делаю в йода-стиле if ( 'val' == $var )

Обёртка хорошая, а для сессии подобный враппер не используете?
>> для сессии подобный враппер не используете?
Да, конечно использую. Но сам объект управления сессиями в моем случае делает намного больше чем просто управлением параметрами. Это аутентификация, а также предоставление данных о текущем пользователе. Иными словами, класс заточен под фрэймворк.
у меня есть замечание по части кода.

> $domain = false, $secure = false, $httponly = false
лучше в таком случае пользоваться null типом.
а проверять if(isset($variable)){...}

в таком случае просто быстрее будет.
Можно ещё добавить сохранения массивов
$_COOKIE['lang'] = array('ru', 'en'); 

Sign up to leave a comment.

Articles