Вот такой метод мне как раз не нравится… хотя бы тем, что в описанном здесь случае чтобы сделать из ветки дев ветку продакшен достаточно просто поменять одну константу :)
Это если локально то да, просто ИМХО когда любой пользователь необходим ресурсу начинаешь задумываться об этом.
Из практики про непользовательские прокси могу рассказать что знаю контору у которых стоит Squid режущий все заголовки кроме базовых — с точки зрения админа это типа «безопасно» + «многие дурацкие сайты не работают» :-D
На самом же деле вопрос намного сложнее, чем ответ.
Разные способы — разные риски.
На мой взгляд самое надежное — запрашивать пароль перед какойлибо «опасной» процедурой.
И в случае если пользователь очень важен ресурсу то больше не проверять ничего. ИМХО.
содержимое $_SESSION не хранится в куках, в куках хранится лишь id сессии, к тому-же это всеголишь пример. Чтобы ничего не ломалось в тойже статье описан способ когда токен выдается на определнное время — что делает этот способ вполне корректным.
Referer увы и ах не панацея — может резаться как проксями так и не выдаваться браузерами, и да,
можно сколько угодно говорить что виноват пользователь :-D
Есть еще один интересный подход, позаимствованный со спектрыма еще, когда бэкбуферов два — один для динамики, второй для фона ( фон медленней меняется чем динамика — например пероснаж и объекты вокруг него — оотвтественно все это отрисовывается в разных потоках ) — при выводе сначала выводится бэкбуфер с фоном потом сверху бэкбуфер с динамикой.
По поводу 1 игра != 1 canvas добавлю от себя, что самый простой и быстрый вариант — это старый добрый спрайтовый подход.
При запуске игры нагенерили спрайты с которыми дальше будете работать, отрисовали их в бэк-буфере ( можно или бак-канвас или imageData ), выкинули на экран и т.д. По сравнению с простой отрисовкой на канвасе скорость получается гораздо более привлекательная
С точки зрения логики да, но работаь с этим делом не удобно. В конце концов это свойство должно влиять на визуальный вид объекта
Я не говрю спецальные какието свойства, которые могут быть присвоены с помощью JS
Или тогда надо делать чтото наподобии CSS но для свойств объекта.
Вообще путаница эта очень давно. теже cellspacing-и и cellpadding-и и т.д.
Ну а если JQ давала возможность свести все это к одной фии — это и было хорошо — потому и одумались.
Так то оно так, однако оно на самом деле сказывается на виде документа — т.е. у тогоже чекбокса галочка появляется. Мне кажется что не было бы ничего страшного убрать это все в css.
Просто частенько (Не в Вашем случае а вообще) такие вещи могут быть из-за плохой орагнизации модели (неграмотное проектирование), которая потом переложена на функционал.
Здесь согласен, но ИМХО при простой иерархии проще читаемо и поддерживаему всетаки функциональное программирование — я не про неймспейсы или чтото другое, а про то, что ради простой задачи где можно обойтись несколькими функциями нет смысла делать ООП вообще. зачем?
:(
Из практики про непользовательские прокси могу рассказать что знаю контору у которых стоит Squid режущий все заголовки кроме базовых — с точки зрения админа это типа «безопасно» + «многие дурацкие сайты не работают» :-D
На самом же деле вопрос намного сложнее, чем ответ.
Разные способы — разные риски.
На мой взгляд самое надежное — запрашивать пароль перед какойлибо «опасной» процедурой.
И в случае если пользователь очень важен ресурсу то больше не проверять ничего. ИМХО.
Referer увы и ах не панацея — может резаться как проксями так и не выдаваться браузерами, и да,
можно сколько угодно говорить что виноват пользователь :-D
В кратце все просто — для каждой формы или опасного действия грубо делается следующее (PHP):
<?php
session_start();
if ( @$_SESSION['token'] && @$_POST["token"] ) {
if ( $_SESSION["token"] == $_POST["token"] ) {
обработка формы
}
}
$token = md5(uniqid(rand(), TRUE));
$_SESSION['token'] = $token;
?>
<form ...>
....
<input type="hidden" name="token" value="<?php echo( $token ); ?>"
</form>
При запуске игры нагенерили спрайты с которыми дальше будете работать, отрисовали их в бэк-буфере ( можно или бак-канвас или imageData ), выкинули на экран и т.д. По сравнению с простой отрисовкой на канвасе скорость получается гораздо более привлекательная
А неудобство в том что есть две сущностии с ними надо както работать по разному.
Я не говрю спецальные какието свойства, которые могут быть присвоены с помощью JS
Или тогда надо делать чтото наподобии CSS но для свойств объекта.
Вообще путаница эта очень давно. теже cellspacing-и и cellpadding-и и т.д.
Ну а если JQ давала возможность свести все это к одной фии — это и было хорошо — потому и одумались.
чем checked хуже display?
тем что установлено не через стиль?
И смысла ИМХО разграничивать тоже никакого не было. Ну и вот — отрефакторили :)
Почему интересно?
Так вроде вполне — цена около 319$
a) задачи
б) специалиста
Надо применять разные подходы в заисимости от задачи.
А дальше дело за тем как это будет реализовывать выбранный специалист.
Просто частенько (Не в Вашем случае а вообще) такие вещи могут быть из-за плохой орагнизации модели (неграмотное проектирование), которая потом переложена на функционал.
Или я не так понял?