Проблемы, связанные с кэшированием русской куклы с наследованием шаблонов

Я использую как Template Inheritance, так и Russian Doll Caching (используядрагоценный камень cache_digests) независимо друг от друга в отдельных частях довольно сложного приложения Rails, с большим успехом.

Я испытываю трудности при совместном использовании двух технологий, что заставляет меня подозревать, что я могу делать что-то не так ...

Для очень простого примера рассмотрим приложение, состоящее из двух контроллеров, ThingOnes и ThingTwos. Это приложение имеет один макет (layouts/application.html.erb ) который просто отображает заголовочный файл с:.

По умолчанию Rails будет искать эту часть в нескольких местах, включая каталог представления для макета (views/application/_header.html.erb ), а также любой специфический для текущего контроллера (например,views/thing_ones/_header.html.erb или жеviews/thing_twos/_header.html.erb ). Это означает, что для целей кэширования у меня в основном есть список зависимостей шаблона (не считая движков или чего-либо еще), например:

[
  "application/header",
  "thing_ones/header",
  "thing_twos/header"
]

Теперь мы обернем этот вызов рендеринга кэшированием следующим образом:


  

К сожалению, работаетrake cache_digests:nested_dependencies TEMPLATE=layouts/application результаты в следующем списке зависимостей.

[
  "layouts/header"
]

Это неКажется, он вообще не заботится о наследовании шаблонов. Изменение файлов, не включенных в список, приводит к ожидаемому эффекту изменения файлов, не включенных в список, - срок действия кэша не истек и отображается устаревший заголовок.

Это можно легко исправить, указав соответствующие пути шаблона, например, так:


  
  
  
  

Это кажется очень плохим решением, так какне растет, и требует много легкомысленного украшения для кэширования вызовов, чтобы сохранить существующее поведение наследования шаблонов.

Точно так же можно более явно указать местоположение заголовка, например так:


  

Это также не позволяет сохранить существующее поведение наследования шаблонов, что делает его непригодным для наших нужд.

Последний вариант заключается в перемещенииcache вызовите в заголовок партиалы сами. Это не только неэффективно, так как оставляетrender вызов из кеша. Он также более ВЛАЖНЫЙ (напишите все дважды), чем СУХОЙ, что является значительным отключением.

Итак, чтобы перейти к моему актуальному вопросу (ям) ... Я делаю это правильно? Это кажется довольно серьезным недостатком, который может повлиять на широкий спектр реализаций, но я могуНа самом деле я не нахожу много дискуссий, связанных с этой конкретной проблемой, поэтому мне интересно, делают ли это другие, которые работают лучше Есть ли лучший способ сделать это, или, по крайней мере, автоматически указать полную иерархию зависимостей шаблона для частичного рендеринга?

 Brad Werth19 июн. 2013 г., 23:15
Я начинаю подозревать, что люди просто несохранение этих кэшей во всех развертываниях или что-то в этом роде ...

Ответы на вопрос(1)

вы должны переместитьcache метод в ваши представленные шаблоны.

Это может показаться большим количеством кода, но это необходимо для правильной работы дайджеста кеша. Кроме того, если ваши частичные (_header.html.erb в приложении thing_ones и thing_twos) различаются, если ключ кеша также будет другим. Это означает, что вы должны получить что-то вроде этого:

# layouts/application.html.erb
<%= render 'header' %>

# application/_header.html.erb 
<% cache 'application_header' do %>
  ...
<% end %>

# thing_ones/_header.html.erb
<% cache 'thing_ones_header' do %>
  ...
<% end %>

# and thing_twos/_header.html.erb
<% cache 'thing_twos_header' do %>
  ...
<% end %>

Без разных ключей кэша эти кэши перекрывают друг друга, что означает, что, например, если.application/_header.html.erb был кэширован первым, то это будет тот, который отображается одинThingOnes а такжеThingTwos страницы.

Ваш ответ на вопрос