ну :) хоть это и немного офтоп, но я бы на вашем месте не стал ручаться за «прозрачность» zf. одна диспетчеризация чего стоит. на этот процесс влияет столько внешних факторов: сплошная магия.
вот что будет после:
в целом согласен, но думаю что область применения подобных техник лежит в другой плоскости: в библиотечных классах и различных апи. вот, например, в доктрине таких «магий» навалом. там это во много оправдано.
«Решай проблеммы по мере их возникновения». Каждый раз себе это повторяю. Часто помогает. А вобще это очень тонкая материя. Тут, как и во всем остальном, серебрянной пули нет.
но есть непонятные баги:
во-первых если быстро рефрешить страницу в нормальном режиме (когда бекэнд отдает 200) nginx через раз показывает закешированную копию. так, будто время жизни кеша 1-2 секунды, а не 1 милисекунда.
во-вторых в «аварийном» режиме (когда апач отдает 503) nginx отдает последнюю имеющуюся у него версию из кеша, но через раз вместо нее предлагает скачать какой-то файл. т.е. просто вываливается диалог сохранения/открытия файла с непонятным именем zEDex4TV.dms.part. причем происходит это бессистемно. мне так и не удалось понять в каком случае он отдает правильную страницу, а когда предлагает вдруг что-то сохранить/скачать. раз 5 показывает последнюю версию из кеша как и надо, а потом вдруг бац.
можно ли кешировать ответы апача, но отдавать всегда свежий контент (ну как если бы мы кешировали с таймаутом в 0 секунд). а в случае если апач возвращает 50х ошибку — выдавать страницу из кеша.
немного сумбурно объясняю, я просто сам еще толком не уяснил для себя как это должно работать.
пример: все работает в штатном режиме — всегда отдается свежий контент без всякого кеширования. но вдруг на бекэнде что-то ломается (допустим отваливается база данных) и бекенд завершает работу с ошибкой 503 допустим. может ли nginx получив такой ответ посмотреть есть ли у него в кеше такая страничка (ее последняя нормальная версия) и если есть — отдать?
а во-вторых кому оно надо? ведь это тоже, то и в rss. лично мне (не буду говорить за всех) проще rss читать, тем более что тот же гуглридер гораздо лучше оптимизирован для чтения на мобильном устройстве. для айфона так практически идеален.
мне бы очень полезна была (крайне, просто мастхев) полная версия постов в рсс, без хабраката. вот за это я сказал бы бооольшое спасибо. а пока приходится искать сторонние решения типа яхо-пайпс.
Хочу чтобы такое же было в Москве.
Надо обязательно будет видео посмотреть.
вот что будет после:
$this->_forward('some-action'); $this->getRequest()->setDispatched(true);Это прозрачно? ;)
Я просто хочу сказать что не всегда удается использовать исключительно ясные и прозрачные методы. Но это не значит, что к этому не нужно стремиться.
?
Ну и рефакторинг никто не отменял.
раз пошла такая пьянка :)
в самом примитивном случае выглядит так:
define('DIR_CONTROLLER', COPY ? '/copy' : '/standart'); require_once DIR_CONTROLLER . '/index.php';Ну а реализация проверки всегда разная и зависит от обстоятельств
Иногда достаточно if (!empty($value)), а иногда нужно и что-то более сложное:
if (isset($_GET['query']) && trim($_GET['query']) !== '') { // ok }ну или в случае с использованием $request:
$query = $request->getParam('query'); if (trim($query) !== '') { // ok }{if $error} <div class="error-msg">{$error}</div> {/if}if (!empty($_GET['query'])) { // do something }а лучше:
if ($request->getParam('query')) { // TODO: решать проблему в корне }Лаконичнее, логичнее и красивее
ls -la /var/cache/nginx/ — всегда пусто (чтобы было понятно о чем я говорю)
притом если поставить например proxy_cache_valid 5m; — то кешируются все запросы на 5 минут
видимо ему нужно как то дать понять чтобы он в кеш писал каждый нормальный ответ апача в независимости от времени жизни кеша
вот так более-менее работает:
но есть непонятные баги:
во-первых если быстро рефрешить страницу в нормальном режиме (когда бекэнд отдает 200) nginx через раз показывает закешированную копию. так, будто время жизни кеша 1-2 секунды, а не 1 милисекунда.
во-вторых в «аварийном» режиме (когда апач отдает 503) nginx отдает последнюю имеющуюся у него версию из кеша, но через раз вместо нее предлагает скачать какой-то файл. т.е. просто вываливается диалог сохранения/открытия файла с непонятным именем zEDex4TV.dms.part. причем происходит это бессистемно. мне так и не удалось понять в каком случае он отдает правильную страницу, а когда предлагает вдруг что-то сохранить/скачать. раз 5 показывает последнюю версию из кеша как и надо, а потом вдруг бац.
стандартная ситуация:
location ~ \.(jpg|gif|png)$ {
root images;
}
location / {
proxy_pass ...;
}
можно ли кешировать ответы апача, но отдавать всегда свежий контент (ну как если бы мы кешировали с таймаутом в 0 секунд). а в случае если апач возвращает 50х ошибку — выдавать страницу из кеша.
немного сумбурно объясняю, я просто сам еще толком не уяснил для себя как это должно работать.
пример: все работает в штатном режиме — всегда отдается свежий контент без всякого кеширования. но вдруг на бекэнде что-то ломается (допустим отваливается база данных) и бекенд завершает работу с ошибкой 503 допустим. может ли nginx получив такой ответ посмотреть есть ли у него в кеше такая страничка (ее последняя нормальная версия) и если есть — отдать?
а во-вторых кому оно надо? ведь это тоже, то и в rss. лично мне (не буду говорить за всех) проще rss читать, тем более что тот же гуглридер гораздо лучше оптимизирован для чтения на мобильном устройстве. для айфона так практически идеален.
мне бы очень полезна была (крайне, просто мастхев) полная версия постов в рсс, без хабраката. вот за это я сказал бы бооольшое спасибо. а пока приходится искать сторонние решения типа яхо-пайпс.