Отказываться от редиректа все-таки не надо.
С редиректом для пользователя сохраняется возможность свободно гулять по истории без предупреждений броузера «сейчас вы повторно отправите какие-то данные».
Т.е. использовать POST запросы только как setter'ы (что-то меняющие на стороне сервера, но ничего не отображающие), а GET — как getter'ы (только отображающие, но никогда не меняющие ничего на стороне сервера) — идеологически правильно.
Более того, если мы переходим по какому-то специальному урлу (линк с картинкой кнопки) и при этом что-то меняется в даных на стороне сервера, правильно и после этого сделать редирект.
Является ли метод потенциально кэшируемым должен определять не программер, класс использующий, а сам метод.
Т.е., как указывалось выше, надо в самом начале детерминированного метода (без side effect'ов и, не зависящий от окружения) поставить проверку на наличие результата в кэше и возврат его в случае успеха.
Чтобы не заниматься копипэйстом эту функциональность можно выделить в одно место. И это, кстати, скорее будет метод My_Cache, принимающий на вход callback (хотя его и из стека можно вытащить) и arguments. Кстати, хорошая идея для доп. функциональности Zend_Cache :)
PS Но что меня все-таки смущает, это уникальность хэша.
Очень интересно, как российские компании относятся к передаче своих данных на сторону (для изучения).
Лет 10 назад плотно работал с DB2 и в дополнение к этому изучал IBM'овский Intelligent Miner for Data (сейчас существует как семейство продуктов DB2 Intelligent Miner).
Уже тогда было очевидно, что штуку можно много где и с толком применить. Но так же очевидно было и то, что никто свою коммерчески важную информацию на сторону не отдаст (а во многих случаях и сам брать не захочешь :))
Что-нибудь с тех пор изменилось?
Или вы создаете клиенту решение, оставляете у клиента, а с самими данными уже не работаете?
Чтобы не приходилось «дискретно» решать мусор это или что-то важное, можно просто использовать яркость/прозрачность контента.
Чуть приглушить «маловажную информацию» и чуть более приглушить «мусор», и чтение станет гораздо более приятным. В то же время это даст возможность все-таки добраться до информации, распознанной как «шум».
Плюс дать возможность по, к примеру, Ctrl-Shift-Mouse Scroll восстанавливать/приглушать яркость и цены такой штуке не будет! А еще если в виде плагинов :)
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
С редиректом для пользователя сохраняется возможность свободно гулять по истории без предупреждений броузера «сейчас вы повторно отправите какие-то данные».
Т.е. использовать POST запросы только как setter'ы (что-то меняющие на стороне сервера, но ничего не отображающие), а GET — как getter'ы (только отображающие, но никогда не меняющие ничего на стороне сервера) — идеологически правильно.
Более того, если мы переходим по какому-то специальному урлу (линк с картинкой кнопки) и при этом что-то меняется в даных на стороне сервера, правильно и после этого сделать редирект.
Т.е., как указывалось выше, надо в самом начале детерминированного метода (без side effect'ов и, не зависящий от окружения) поставить проверку на наличие результата в кэше и возврат его в случае успеха.
Чтобы не заниматься копипэйстом эту функциональность можно выделить в одно место. И это, кстати, скорее будет метод My_Cache, принимающий на вход callback (хотя его и из стека можно вытащить) и arguments. Кстати, хорошая идея для доп. функциональности Zend_Cache :)
PS Но что меня все-таки смущает, это уникальность хэша.
Но, кстати, по тем временам еще была жива OS/2. И зря, надо сказать, её умертвили.
Лет 10 назад плотно работал с DB2 и в дополнение к этому изучал IBM'овский Intelligent Miner for Data (сейчас существует как семейство продуктов DB2 Intelligent Miner).
Уже тогда было очевидно, что штуку можно много где и с толком применить. Но так же очевидно было и то, что никто свою коммерчески важную информацию на сторону не отдаст (а во многих случаях и сам брать не захочешь :))
Что-нибудь с тех пор изменилось?
Или вы создаете клиенту решение, оставляете у клиента, а с самими данными уже не работаете?
Чтобы не приходилось «дискретно» решать мусор это или что-то важное, можно просто использовать яркость/прозрачность контента.
Чуть приглушить «маловажную информацию» и чуть более приглушить «мусор», и чтение станет гораздо более приятным. В то же время это даст возможность все-таки добраться до информации, распознанной как «шум».
Плюс дать возможность по, к примеру, Ctrl-Shift-Mouse Scroll восстанавливать/приглушать яркость и цены такой штуке не будет! А еще если в виде плагинов :)