Что за ерунда?!
Прекрасно AppStore принимает российские карты.

itunes.apple.com/us/app/unearthed/id370826160?mt=8
www.tuaw.com/2010/09/16/tuaws-daily-app-unearthed/

Ага, вот мы и подобрались к тому, о чем моя заметка. ;-) Что, если article_list - не QuerySet, а результат нескольких запросов, да еще и обработанных программой? Автоматически ленивая загрузка тут может не получиться. И именно в таком случае и пригождается возможность подготовить операцию, не выполняя ее.
Ленивая загрузка коллекций у меня тоже есть, но не всегда удается обойтись автоматикой.

Значит, я правильно понимаю, что фактически исполнение кода article_list=Article.objects.filter(tags=tag, public=True) происходит только когда в шаблоне происходит {% for article in article_list %}?

Что-то я не очень понимаю.

<code>

{% block content %}

	{{ tag.title }}

	{{ tag.text }}

	{% cache 500 article_list tag.id page %}

		{{ block.super }}

	{% endcache %}

{% endblock %}

</code>

Откуда именно здесь появляется список статей? Где именно написан код для доставания его из базы?

Э, нет, не о том мой "велосипед" был!
У меня там вместо этих блоков было бы $this->render_action('list', 'article');
Это не то.
Покажите-ка, пожалуйста, кэширование списка статей на странице списка статей. Вот на blog/index.htm в Вашем примере.

Обязательно почитаю.

Ну что ж, действительно, при таком подходе (похоже на Code Igniter, что ли) так будет совсем красиво. У меня-то переменные в шаблоне уже просто как $product, $category, $books и т.п. появляются, так что __call или __get некуда приделывать.
Замечательное развитие мысли, спасибо.

Спасибо за подсказку про строку, проверю, не знал.

Да не то это, это как бы компонент кэшируется целиком.
У меня про другое совсем, см. в апдейте.

Да, это очень похоже, но не совсем то.
В документации: $res = $cache->foobar('1', '2');, то есть для выполнения закэшированного нужно все-таки знать, ЧТО должно выполниться.
У меня же этого знать не нужно. Знаем мы только в контроллере, а в шаблоне всегда одно и то же: $res = utils::run( $res );
Повторюсь: я и так использую Zend Cache, обернув его своим cacher.

Так никто же не вызывает ничего подобного. Код читали?

Это, между прочим, вопрос - что лучше? Настраивать отдельно (и помнить об этой новой связи) или выполнять действия именно там, где они нужны.
Потом, во view придется все-таки указать сам блок для кэширования, это и сделано.
Заметка все равно не об этом, а только о маленьком нюансе.

Да, похоже.

Написал апдейт, пояснил.

Написал апдейт, пояснил.

Спасибо за возможность.

Так и делаю, написал выше. Иногда все-таки не все удается разбить, или это породило бы массу дублирования. Пример с последними товарами выбран для простоты. Показательно, что автор подкаста столкнулся именно с проблемой, для которой я предложил решение. То есть это не только мне нужно. ;-)

Я тут писал не про само кэширование, оно-то у меня именно с помощью Zend Cache и сделано. cacher - это мой класс-обертка, для компактности.

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